Dynamics AX Development and Customization Best Practices- code comments

In previous article we have covered coding best practice for Naming conventions and I this article we will cover the best practice guidance for writing code comments.

  • Comments should be used to describe the intent, algorithmic overview, and logical flow.
  • Provide comments so that someone other than the original developer can understand the behavior and purpose of the code.
  • As a best practice, most code has comments reflecting the developer’s intent and approach for the code.
  • Use comments liberally.
    • Include comments that indicate who made the changes.
    • when the changes were made,
    • Why the changes were added.
    • What the changes you do.
  • Comments are particularly beneficial when multiple parties are involved in modifying and maintaining code.

Developers should follow the following guidelines for writing code comments:

  • Do not use comments that repeat the code.
  • Do not use multi-line syntax, /* … */, for comments. Single-line syntax, // …, is preferred, even when a comment spans multiple lines.

Example:

public int getSum()

{

;

// This comment spans multiple

// lines because it has

// a lot to say. The use of

// multi-line syntax is

// not allowed.

}

  • Do not place comments at the end of a line, unless the comment is very short. In most cases, comments should be placed above the code.

Example:

public class ArrayList

{

int count; // -1 indicates uninitialized array

}

  • Remove TODO comments well in advance of a release.

Example:

// TODO: The TODO comments should start with TODO.

Comments should not include:

  • Dates
  • Names
  • Aliases
  • Version or layer references
  • Bug numbers – unless it is a workaround, or unless the code could appear inappropriate if you didn’t know that it was for a bug fix.
  • Politically or culturally sensitive phrases
Advertisements

Microsoft Dynamics AX 2012 SSRS Reports Considerations

Things we must remember while working with SSRS reports whether it is customized or new reports from scratch.

  • All servers must be using Microsoft Windows authentication. Depending on the functionality that you implement, Microsoft Dynamics AX may also require that you use domain accounts with specific permissions.
  • When upgrading, existing Reporting Services and X++ reports will be copied to the Microsoft Dynamics AX 2012 system, but they will not be upgraded. We recommend that you use a Reporting Services report that is provided with Microsoft Dynamics AX 2012 as a template and customize it to meet your needs
    • Reports will not be upgraded from Microsoft Dynamics AX 2009 to Microsoft Dynamics AX 2012. Microsoft Dynamics AX 2012 provides hundreds of default, out-of-the-box reports that you can deploy and customize
  • When accessing data from the Microsoft Dynamics AX database
    • use the predefined Microsoft Dynamics AX data sources to ensure that appropriate security is enforced
    • When you use the query and report data provider data source types, all data access requests go through the Role and Task security system
    • When you use an external SQL or OLAP data source, security settings from the Role and Task security system are not applied when accessing data
      • In this case, you can use the role-based security features that are available from Microsoft SQL Server to secure the data.
  • Try to put static debugger (write breakpoint) in DP Class processReport() method.
  • Run the report from visual studio
    • Open Microsoft dynamics AX Configuration Utility -> select developer tab,
      • Select check boxes provided) and debug it.
  • Stress (While Debugging) on query in processReport() methods
    • Because that could also be one of the reason for your problem.
  • Put static debugger in insertIntoTempTable() as well to check whether data is populating in temp table or not, change TableType as regular.
  • Refresh Report, Report Server in Tools-> Caches ->Refresh report server
  • Delete the Report from report Server and redeploy it.
  • Generate Incremental CIL.
    • Full CIl generation (Recommended)
  • Do not build third-party reporting projects from the command line. Build from the command line only in trusted scenarios
    • When building from the command line, Microsoft Dynamics AX reporting tools does not perform any checks for unsafe entries in the project file
    • The project file entries are not analyzed by Microsoft Dynamics AX reporting tools from a security perspective

Dynamics AX Development and Customization Best Practices-Naming conventions

In previous article we have covered coding best practices of code formattings in this article we will cover the Naming conventions:

Naming conventions contribute to consistency and to making the application easier to understand. Naming conventions contribute to consistency and to making the application easier to understand. I think that the basic rule to create good naming conventions is to do it with following guidelines.

  • Use Camel Casing for member variables, method names, and local variables. E.g. serverClass;
  • Use Pascal Casing for AOT elements. E.g. AddressCountyRegion;
  • Prefix parameter names with an underscore (_). E.g. myJob(Args _args)
  • Do not use Hungarian notation. Do not encode the type of a variable in its name. E.g. strName
  • Avoid prefixing local variables. E.g. stringName or intCount
  • Use meaningful and self-documenting names.

Object names best practice:

Object names should not be hard-coded. If the objects are renamed or removed in future version, hard-coded names do not result in compilation errors and are very difficult to find.

It is always better to wrap object names in methods such as formstr(..) and tablestr(..), because they result in a compilation error and easily surface naming issues.

In this example, object names are hard-coded in code.

Args = new Args(‘SalesTable’);

methodName = ‘runXyz’;

In this example, object names are wrapped with correct methods.

Args = new Args(formstr(SalesTable));

methodName = tablemethodstr(SalesTable,runXyz);

Dynamics AX Development and Customization Best Practices-Code formatting recommendations

Some Dynamics AX customization best practices are applicable irrespective of AOT element. These standards include X++ standards includes:

  • Code formation
  • Naming conventions
  • Label standards
  • Help Text guidelines.

In this article we will cover some best practices related to the X++ language specially Code formatting recommendations.

Following are the Code formatting recommendations:

  • Place the opening brace at the beginning of the next line.

Example:

if (someExpression)

{

doSomething();

}

  • Align the closing brace with the corresponding opening brace.
    • Example

if (someExpression)

{

doSomething();

}

  • Place each opening and closing brace on its own line.
    • Example:

if (someExpression)

{

doSomething();

}

  • Do not omit braces. Braces are not optional, because they increase code readability and maintainability. They should be included even for single-statement blocks.

Example:

if (someExpression)

{

doSomething();

}

  • Omit braces for switch statements. These braces can be omitted, because the case and break statements clearly indicate the beginning and end.

Exampole:

case 0:

doSomething();

break;

  • Use a single space in the following cases:
    • On each side of an assignment operator

Example: cust.Name = “abc”;

    • After the comma between parameters

public void doSomething(int _x, int _y)

    • Between arguments

myAddress(myStr, 0, 1)

    • Before flow control statements

while (x == y)

    • Before and after binary operators

if (x == y)

    • After the semicolon between the parts of a for statement

for (i = 0; i < 10; i++)

  • Do not use any spaces in the following cases:
    • After an opening parenthesis or before a closing parenthesis

myAddress(myStr, 0, 1)

    • Between a member name and the opening parenthesis

myAddress()

    • After an opening bracket or before a closing bracket

x = dataArray[index];

    • Before or after unary operators

if (!y)

  • Use four spaces as the standard indent. In the code editor, the Tab key inserts four spaces. Indent in the following cases:
    • The contents of code blocks

if (someExpression)

{

doSomething();

}

    • Case blocks, even though they do not use braces

switch (someExpression)

{

case 0:

doSomething();

break;

}

    • A wrapped line one indent from the previous line

lastAccount = this.doSomething(

cust,

firstAccount,

startDate,

endDate);

    • Wrap lines that are too long to fit on a single line.
    • Wrap shorter lines to improve clarity.
    • Place each wrapped select and while select statement keyword at the beginning of a new line. The content associated with each keyword should be indented by one indent under the corresponding keyword.

select firstonly cust

where someExpression1

&& someExpression2

&& someExpression3;

select count(RecId)

from cust

where someExpression1

&& someExpression2

&& someExpression3;

while select firstonly cust

order by Name, AccountNum

where someExpression1

&& someExpression2

&& someExpression3

{

}

    • Do not use more or less than four spaces to force special alignment.

lastAccount = this.doSomething(

cust,

firstAccount,

startDate,

endDate);

Mostly developer use it as (This is wrong)

last = this.do(

cust,

firstAccount,

startDate,

endDate);

    • Put each indented parameter or argument on a separate line.
    • Use switch statements instead of consecutive if statements.
    • Do not use parentheses around the value of the cases of a switch statement.
    • Do not put the closing parenthesis for a method call on a new line.

Dynamics AX Development and Customization Best Practices-Customizing code

Developments are now shared among diverse team, sometimes across multiple partners and outsourced to vendors, meaning different skills and processes. Therefore such well known issues still remain in production when customized best practices rules and internal review are not properly defined.

Flexibility is maybe the number one strength of the product, but it can also leads into performance issues if the customized code doesn’t match the Microsoft Best Practices.

Optimize the code with the 10/10/80% application rule:

  • 10% of the performance can be explained by infrastructure issues like network, disk latency, memory pressure and high utilization processors
  • 10% by wrong configurations in SQL and AX such as Max degree of Parallelism, database files size and location, AX Database logging and Number Sequences
  • Then 80% can be found its root cause in the business logic X++ code in correlation with index tuning and data modelling.

I this article we will cover the Custom code standards and best practices.

  • If base layer code needs to be replicated or used at other places, it is always better to extend the existing classes and modify the derived class for the change in behavior, rather than creating completely new classes and then copying entire code from the base class.
    • Makes it easier to upgrade code:
      • When base layer code is changed, it must be replicated again.
      • If you have created an extension, only the modified code must be restructured.
  • Create classes and methods so that the same piece of code can be reused in multiple places.
  • Avoid creating long methods. They make code difficult to read, hard to debug, and extremely difficult to upgrade and maintain.
  • Remove dead code to avoid upgrade and maintenance costs.

Add custom code

  • Create customizations in the appropriate location.
  • Create code for reuse as much as possible.
  • Create it at the lowest appropriate location.

For example:

If anything is required only in a form do not put it at the table level.

The following examples describe where we recommend that you place the code:

If it is related to the UI, place the code on the appropriate UI elements, or create classes to handle scenarios specific to the UI.

For example: you can create classes that handle controls, number sequences in forms, dialog boxes, and so on.

  • If it is related to a business process, place the code in classes.
  • If it is directly related to tables and schema, place code on the tables.
  • Consume existing Microsoft Dynamics AX classes and services instead of directly querying tables.
  • Become familiar with the base layer features.
  • Do not write custom code that duplicates base functionality.

Important: Directly updating or deleting data from Microsoft Dynamics AX tables is not supported.

Coding standards

The following list provides coding standards to follow:

  • Favor the use of positive logic.
  • Use constants instead of numeric literals.
  • Use enumerations instead of constants.
  • Use explicit access modifiers.
  • Do not use method parameters as an l-value.
  • Arguments passed in a method should not be modified, and only the value should be used.

Dynamics AX Development and Customization Best Practices-Coding

When using the Microsoft Dynamics AX development environment, you should follow a set of best practices. The X++ compiler checks the code for best practice issues. These issues can result in best practice errors, warnings, or informational messages.

In this article we covers Microsoft Dynamics AX application development best practices. They are recommended for any Microsoft Dynamics AX partner or end user who is developing or customizing Microsoft Dynamics AX.

These best practices apply to the following:

  • Programming in the standard application
  • Certified solutions

Following are the steps to check code and application objects for compliance with the best practices for Microsoft Dynamics AX.

  • Open AOT by using short Key (CTRL+D)

  • Select Tools > Options from above screen the following window will be shown

  • Click the Development from left panel of above screen.

    • Click the Best practices button. On above screen and the following popup window will show.

  • As in the above screen the following Warning level list you can select that you want to perform also layer can be selected on which you want to perform best practice.
    • Errors only
    • Errors and warning
    • All

Note: the best practices are checked when you compile or check in an object.

We can also check best practices for one or more nodes in the Application Object Tree (AOT): right-click the node, and then select Add-Ins > Check Best practices.

Output will be shown with the following severity code:

  • Information: Things that might be nice to know (shown in blue).
  • Warnings: Things that you should strongly consider fixing (shown in yellow).
  • Errors: Things that should definitely be fixed (shown in red).

In next article we will cover the Pest Practices of code Customization standards.

Dynamics AX Development and Customization Best Practices-Services

Use services to code business processes. Microsoft Dynamics AX 2012 supports the following services:

Document services:

Document services are query-based services that can be used to exchange data with external systems by sending and receiving XML documents. These documents represent business entities, such as customers, vendors, or sales orders.

Custom services:

Custom services can be used by developers to expose any X++ logic, such as X++ classes and their members, through a service interface.

System services:

System services are provided by Microsoft Dynamics AX. System services include the Query service, the Metadata service, and the User Session service. System services are not customizable, and they are not mapped to any query or X++ code.

Best Practice:

Developers should use the existing services exposed in the Microsoft Dynamics AX base layer. Expose any new business processes through services.