The Style Guide is based on what is, to some degree, a fiction: that application development issues can be nicely divided between mechanism on one hand and policy and style on the other. In theory, the mechanisms of DCE programming refer to the syntax and semantics required by APIs, IDL constructs, services, and the like. These are the things about which the programmer has no choice: they must either be done according to the documentation or not done at all. Policy and style, on the other hand, are supposed to refer to the things about which the programmer can make a choice: specifically, which mechanisms to use in given circumstances.
In practice, the distinction between mechanism and policy/style is often vague. The other parts of the DCE application development documentation set contain much that could be considered policy and style guidance. And, for reasons discussed in some detail in the next topic, the Style Guide often contains descriptions of the mechanisms of DCE programming.
Nevertheless, the Style Guide does attempt to keep to the ground of policy and style issues. It assumes that you already know what mechanisms are available and attempts to provide guidance about the choices you have in using those mechanisms. One result is that the Style Guide is not a tutorial; it often assumes knowledge of terms and concepts that are explained elsewhere in the programmer's documentation.
On the other hand, the Style Guide does in many cases provide high-level discussions of the organization and principals of DCE services, such as the security services. The assumption is that you may already know many of the details but may lack an overall framework. Often, such a general model is just what you need to be able to make rational policy decisions.
The distinction between policy and style is itself somewhat vague. In general, policy refers to the things you should do in an application program. You can usually identify a policy recommendation because the words "should," "must" or "recommended" appear. Style is a more general term that includes policy (hence Style Guide), but that also covers a variety of other suggestions about how you might do things. Much of the sample code included in the Style Guide embodies not only the recommended policies, but also provides illustrations of possible styles of usage. Such suggestions are intended to be helpful, but unless they are couched in the language of policy, should be considered entirely optional.