Source File Content

Article
09/22/2010

[This content is no longer valid. For the latest information on "M", "Quadrant", SQL Server Modeling Services, and the Repository, see the Model Citizen blog.]

The following Microsoft code name “M” conventions provide general guidelines for organizing the content of an “M” source file.

Do Include a Copyright Statement

Place a copyright statement in a comment block at the beginning of each “M” source file. Leave a single blank line between the copyright statement and the module declaration. The following code sample shows an “M” file that follows this guideline.

//------------------------------------------------------------------------------
// Copyright (c) Microsoft Corporation. All rights reserved.
//------------------------------------------------------------------------------

module Contacts
{
    import System;

    // Additional Implementation Code Not Shown
}

Do Use Separate Files for Each Type, Extent, or Computed Value

As a general rule, declare all types, extents, and computed values in separate files. This improves discoverability and reuse, and it localizes the impact of changes to affected files. This is especially important for types that are referenced by other types and extent definitions.

There is a known exception to this rule. If a type is declared to express all or part of the definition of an extent but is not reused in other extent or type definitions, the type can be declared in the same file as the extent it defines. In this case the file should be named for the extent and not the type.

Do Leave a Blank Line between Imports and Exports

List all imports first followed by all exports. Use a blank line to visually separate the two groups. The following “M” code provides an example of this guideline.

import System;
import System.Application;

export Person;
export Persons;

Do Declare Each Import and Export on Separate Lines

Although it is syntactically correct to separate a list of imports or exports with commas, it is more difficult to read. Improve readability of the “M” source code by using separate lines for each import or export statement. The following “M” is an example of the correct way to list multiple import and export statements on separate lines.

import System;
import System.Application;

export Person;
export Persons;

Avoid code similar to the following example that puts multiple export and import targets on the same line.

import System, System.Application;

export Person, Persons;

Do Organize Imports Hierarchically

Organize import statements hierarchically, with higher-level modules imported before lower-level modules. In this guideline, a higher-level module is more abstract or generic than a lower-level module. A lower-level module might define a specific area within the higher-level domain. Consider the following “M” import statements.

import System;
import System.Application;

The System module is more abstract, because it models entities that are used by many other modules and types in this domain. The System.Application module is lower-level, because it models entities that apply only to application-based systems.

Do Not Export Constructs that are Not Referenced from Other Modules

Do not export types, extents, or computed values unless other modules require references to those constructs. Types, extents, and computed values can be referenced from within the same module without being exported. This is true even if the module is defined in many different “M” source files. Export only types or extents if they are meant to be referenced from other modules.

Do Export a Type before its Corresponding Extent

When the type and extent definitions exist in the same source file, declare the export statement for a type before the export statement for its corresponding extent. The following “M” code follows this guideline with a Person type that defines a Persons extent.

export Person;
export Persons;

Note

This guideline applies to a scenario where the type and extent are defined in the same “M” source file. This scenario should only happen when the type is not externally referenced and is used in the full definition of a single extent. In all other cases, use separate source files for types and extents.