Best practice parameters

Article
05/18/2015

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Best practice checks help to make sure that the best practice guidelines are followed. Use the Best practice parameters form to select which best practice checks to verify.

Select from the Warning level: drop-down to specify the kinds of messages produced. The warning levels are as follows:

Errors only - Messages only about best practice errors.
Errors and warnings - Messages only about best practice errors and warnings.
All - Messages about violations to all best practices checks.

Select from the Layer setting: drop-down to specify the layers that will be checked for best practice violations. The layer settings are as follows:

Check all nodes – All layers will be checked for best practice violations.
Skip nodes from lower layers – Only the nodes defined in the current layer and above will be checked for best practice violations.

Use the check box to select or clear individual checks.

Note

Disabling a check suppresses the messages about violations to the check, not the check itself.

The following table provides information on the best practice checks.

Check	Description
Best Practice checks	Select or clear this check box to select or clear all Best Practice checks.
General checks	Select or clear this check box to select or clear all best practice checks under the General checks node.
Properties	Check the use of default values on properties. This option checks only the properties where default values are expected. The setup of properties that do not have default values is evaluated by other, more specific, checks.
Unique tree node names in the AOT	Check whether the tree node names are unique in the Application Object Tree (AOT). Each path in the AOT must be unique. This means that within a node identical names must not exist.
Object ID	Check for changed legacy IDs, name, and origin compared to the base line version.
AOS Performance	Check Application Object Server (AOS) performance. Check that methods are bound to the client or server tier in the most optimal way regarding performance.
Trustworthy Computing	Check whether trustworthy computing best practices have been followed.
Existence of referenced application objects	Check the existence of referenced application objects. This check scans specific areas to see whether the specific referenced application object exists. Also examines whether a field of a specific data type is sufficiently long enough to hold the related value.
Use of discontinued functionality	Check whether functionality used in the system has been replaced by new features. If an application object is planned to be discontinued in an upcoming version, it is a best practice to not use the application object in this version. This check scans for usage of objects that are planned to be discontinued. Note It is possible that other application objects that are not checked by this method might also be discontinued.
Record and table ID references	Check that metadata is valid for fields that contain record or table ID references.
Configuration Keys	Check the use of configuration keys. Each configuration key should have a unique name and ID.

Labels	Select or clear this check box to select or clear all best practice checks under the Labels node.
Use of labels	Check the use of labels.
Use of labels for Help	Check the use of labels for Help text. This check examines whether labels are used on Help properties, and also whether they are used correctly. The following list describes the main rules about how to use labels for help. Use labels for user interface text. Use quotation marks for user interface text in the source code. Help must not be a copy of the elements label. Sentences must always end with a period.

Specific checks	Select or clear this check box to select or clear all best practice checks under the Specific checks node.
Tables	Select or clear this check box to select or clear all best practice checks under the Tables node.
Unique labels	Check whether table fields have unique labels. Examines the table fields and the display and edit methods to make sure that the user interface texts are unique. If a display or edit method does not use an enumeration value or an extended data type as a return type, a warning will be displayed.
Use of indexes	Check the use of indexes. The following list describes the various areas that are checked. Cluster index – Tables with only one index should have that index defined as a cluster index. Primary index – A primary index should be defined if there is a unique index. The use of the RecID value. No overlapping indexes.
Delete actions	Check the use of delete actions. Checks that tables do not have delete actions pointing to each other. If Table A has a delete action to Table B, it is not valid for Table B to have a delete action to Table A.
Declared title fields	Check that the title fields have been declared. The two best fields for the TitleField1 and TitleField2 fields must be declared. The following list describes the guidelines. TitleField1: The key field for the records in the table. TitleField2: The description for the records in the table. For example: TitleField1: ItemGroupId TitleField2: Name
Form reference	Check the existence of the referenced menu item. Checks whether a referenced display menu item that links to the View details form exists for certain table types, or if it is explicitly declared on the FormRef property. The default form is the form that the system displays when the user starts the View details action by using the shortcut menu for a field on a form. The form is referenced through a menu item the Display type. If the FormRef property is left blank, Microsoft Dynamics AX attempts to open a form that has the same name as the table.
AxBC fields	Check the use of AxBC fields.
Use of labels for developer documentation	Check whether labels are used for developer documentation. The DeveloperDocumentation property is used to describe the purpose of an element so that application developers are able to understand what the element is used for. The DeveloperDocumentation property appears in the Properties window for tables, views, and maps. The description provided for the DeveloperDocumentation property is typically no more than five sentences, and is written as a single paragraph. This check examines the value entered for the DeveloperDocumentation property to ensure that labels are used. If a string rather than a label is used, an error displays indicating that the property must contain a label ID. If nothing is entered for the DeveloperDocumentation property, no warnings or errors display.
Fields belong to a field group	Check whether fields belong to a field group. Any field that appears in the user interface must belong to a field group. This menas that field groups can always be used when you design a form. A field group must be defined when several fields logically belong together and are shown together on forms and reports. Field groups must be named by using a label on the Name property. The following is a list of standardized group names. Identification Description Administration Address A module name; for example, Ledger Setup Dimension
Field name/Method name conflict	Check a table does not have a field and a method with the same name.
Financial dimensions	Check whether fields intending to hold foreign keys to a LedgerDimension (DimensionAttributeValueCombination.RecId) are properly defined in the table. Fields must adhere to the following standards: The field name must contain LedgerDimension. For example, OffsetLedgerDimension, or PostedLedgerDimension. The field must extend an EDT that extends LedgerDimensionBase. For example, LedgerDimensionAccount, or LedgerDimensionDefaultAccount. The field must not directly extend LedgerDimensionBase. The field must have a proper Primary Key Foreign Key relationship set up to the DimensionAttributeValueCombination table RecId field.
Number of fields in field groups	Check the number of fields in a field group. A field group must be defined when several fields logically belong together and are shown together on forms and reports. Field groups must be named by using a label on the Name property. The AutoReport field group is defined on every table. AutoReport At least two fields must be included in the AutoReport field group on each table. These are the fields that the user expects to print when Print is clicked from the File menu. Often the fields specified for the TitleField1 and TitleField2 properties are candidates for the AutoReport field group. Dimension The dimension field must be the only field in the Dimension field group.

Currency code fields	Check the use of the CurrencyCode related properties. The CurrencyCode property must be set on all fields by using an extended data type derived from the Money system type, if the AnalysisVisibility property is set to High, Medium, or Low. It should not be set on any other fields. You must set CurrencyCode to SecondaryCurrency if the field uses an extended data type derived from AmountMSTSecondary; otherwise, set it to CurrencyCodeField. If the CurrencyCode property is set to CurrencyCodeField, you must also set the CurrencyCodeTable property to the table that contains that field, or to a table for which a relationship exists from the table that contains this field, and in which a unique index exists for the fields on the target end of the relationship. If CurrencyCode is set to CurrencyCodeField, you must also set the CurrencyCodeField property to a field that uses an extended data type derived from the CurrencyCode property. Note Do not use master currency amounts to set the CurrencyCode properties, because master currency amounts are always in the master currency for the associated company.
Currency date fields	Check the use of the currency date fields.
Check table relations	Check that related string fields have the same length and justification.
Use of labels for entity relationship role	Check whether labels are used when describing the role of a table relation. The EntityRelationshipRole property is used to clarify the semantics of a relationship defined on a table. A role name should be either a noun or a noun phrase. The role name should indicate the role of the associated table in relation to the associating object, or it should be a short phrase that starts with a present-tense verb that indicates the role that the table plays in the relationship. Role names are not required when the relationship is unambiguous. This check examines the value entered for the EntityRelationshipRole property to make sure that labels are used. If a string instead of a label is used, an error displays indicating that the property must contain a label ID. If nothing is entered for the EntityRelationshipRole property, no warnings or errors display.
Unit of measure upgrade	Check that an upgrade rule is set for all tables that use unit of measure.
Check for identical right and left parts of relation	Check whether normal relations contain identical fields from the same table.It is not a best practice to have identical fields from the same table belong to the same normal relation.
Table collections	Select or clear this check box to select or clear all best practice checks under the Table collections node.
Relations	Check that the referenced tables exist in the table collections.
Classes	Select or clear this check box to select or clear all best practice checks under the Classes node.
Abstract	Check that abstract classes are marked abstract. A class must be marked as abstract if it extends an abstract class and does not implement all the abstract methods. This can cause runtime errors when the abstract method is called.
RunBase implementation	Check that classes are implemented according to the guidelines in the RunBase framework. This check examines whether the description method is implemented. RunBase framework implementations must have a static description method.
Missing member function	Check the class for missing member functions. Check that the class is not empty meaning no member variables and no methods. The possible inheritance and declaration of variables are checked to determine if a member should be present. At least one member function that does not calculate the ClassDeclaration must always be present in a class.
Constructors	Check the implementation of class constructors. This check validates that each class contains a static construct method.
Methods	Select or clear this check box to select or clear all best practice checks under the Methods node.
Empty methods	Check for methods with no code. By checking for empty methods, you can detect whether any member functions have been created and left in the system without any code.
Date features	Check the use of date features. By checking the overall use of date features, you can check various problems related to date functionality. It is typically not necessary to format a date to a string. Instead, use date fields, variables, and date controls directly on forms and reports. Never permanently store a date in anything other than a date field. If you must format a date to a string, do the following: For user interface situations - use strFmt, or date2str with -1, in all the formatting parameters, to use the formatting the user has specified in Regional Settings. For other specific system related situations, such as communication with external systems - use date2str, with the relevant parameters dictated by the situation. If Regional Settings dictates the format, be aware that the format can change from user to user, and that it might not be a suitable format for external communication. When you use date2str, always make sure that the resultant string can be held in the receiving place. For example, ensure that the receiving variables are long enough. Str2Date Using str2date indicates that dates are being used that have previously had a string format. Today The system date provided by the today function should be used only where the actual machine date is needed. Most application logic should use the system function systemDateGet, which holds the logic date of the system.
Access modifier	Check whether the access modifier of a method can be set to private, protected, or public based on how it is called. This check examines how the access modifier of a method can be set to private, protected, or public, based on where it is called from. A tip will be displayed if the access modifier of the method has not been set, and: the method can be set to private instead of public. -or- the method can be explicitly specified as public. If the programmer has explicitly specified any of the possible access modfiers, the check is skipped. The compiler will check whether combinations are possible.
Print & pause	Check the source code for the use of print and pause statements. Avoid the use of print and pause statements for any purpose other than testing.
Use of variables	Check how variables are used. This check examines how variable are declared and used. Unused parameters and variables will be exposed. Additional checks for good programming styles, such as some of the naming rules of variables, are also covered by this check.
Future reserved words	Check whether any names conflict with future reserved words. This check examines whether a word is used that might be treated as a reserved word in an upcoming version. It is not possible to predict all future reserved words, but the check includes the words that are most likely to be used.
Text in single quotation marks	Check the use of text in single quotes. This check examines whether system-oriented text in the source is written in single quotes. The system must be maintainable, so if a text or a numeric constant is used with the same meaning in more than one place, the text is defined as locally as possible: a member function, in a class declaration, or globally in a macro. Always consider an alternative way to get the "constant"; often, it is defined in another place, from where it can be reused.
XML documentation	Check the XML documentation for errors. This check verifies that the XML documentation comments are properly formatted and contain required information. The following list describes the main rules. Tag pairs must match containing an opening and closing tag. Documentation is missing after certain tags are used.
Version control references	Check whether referenced elements are under version control.
SysOperation label attribute	Check whether a label defined is a label ID and not a string. When using the SysOperationLabelAttribute or SysOperationGroupAttribute attributes, you can specify the label as part of its constructor.
Forms	Select or clear this check box to select or clear all best practice checks under the Forms node.
Form style	Check that the form follows user experience guidelines for the specified style of the form.
Form size	Check that the form size does not exceed the maximum size. A form must fit into a screen with a resolution of 1024x768 pixels. If the screen resolution exceeds 1024x768 pixels a warning is issued. If the screen resolution exceeds 1280x1024 pixels an error is issued. To calculate the form size, the check will open and close the form, and will therefore cause the screen to flicker.
Disabling technique	Check the setup of form control disabling. The following list describes how fields that the user should not be able to change should be set on the property sheet or from code. AllowEdit: Set to No, so that the user cannot change the value. The AllowEdit property is available on each field in a table, each field in a form data source, and each control on a form. If AllowEdit is set to No, set it as close to the table field as possible. Skip: Set to Yes. Set Skip to Yes if the user should not enter the field when he or she is tabbing through the form. Enabled: Set to Yes. The user can explicitly navigate to the field to see the Help text or to copy the field value.
Control names	Check the naming of controls. This check validates that each control on a form has a unique name.
Tab	Check the form has correct tab pages with correct captions.
Perspectives	Select or clear this check box to select or clear all best practice checks under the Perspectives node.
All analysis visible objects are included	Check that all perspectives contain a configuration key, have a label, and have help text.
Workflow	Select or clear this check box to select or clear all best practice checks under the Workflow node.
Workflow categories	Check the properties of workflow categories. This check verifies that the workflow category properties are correctly configured for execution.
Workflow types	Check the properties of workflow types. This check verifies that the workflow type properties are correctly configured for execution.
Workflow approvals	Check the properties of workflow approvals. This check verifies that the workflow approval properties are correctly configured for execution.
Workflow tasks	Check the properties of workflow tasks. This check verifies that the workflow task properties are correctly configured for execution.
Application Integration Framework	Select or clear this check box to select or clear all best practice checks under the Application Integration Framework node.
Entity and Data Objects Classes	Check that data objects are current. This verifies that the data objects are synchronized with the underlying artifacts that were used to define the data object. The best practice check is for missing or extra methods in the table. Use the Update document service form to keep the data objects synchronized with the underlying artifacts.

Share via

Best practice parameters

See also

Additional resources