2015 m. gegužės 15 d., penktadienis

AX Source Code Quality: What is a Bad Source Code?

Hello AX World,

During my short career I have had a chance to see lots (50+) of different AX implementations and solutions from various countries. I have seen both good and bad code. Unfortunately, in most of the cases it was a bad code. And its a problem, because a person who is reading a bad source code can get frustrated quickly.

But what is a bad code? Why it's bad? How to make it better? To answer these questions and to help you to write a better code I am going to start a series of blog post regarding AX source code quality. I am also open for discussions as there are many arguable topics (e.g. code commenting).

I will start my first post with an example to consider:

Keep in mind, this is an overridden method in a class extending RunBase class (from RunBase framework. Ignore the fact that RunBase is an obsolete framework in AX 2012.

How many bad practices can you notice? Before reading it further try to test yourself.
So, how many issues you have noticed? 1, 2, 3,... more?

Let's try with some bad practice basics.

1. Application elements should be started with a capital letter to easily distinguish them among variables.
2. Brackets missing around if statement even if its a single line for a better readability.
3. There should be a single space between addition operators.
4. There should be a single space after a separator.
5. Redundant empty line.

Got the idea? Now lets move on with more sophisticated issues.

6.There should be a single label and preferably strfmt function be used instead  of two labels and a number of adding operators.

7. Instead of calling infolog.add method, error method could be called as it contains the same code and requires only one parameter, the text.

8. Validation logic should be moved to a validate method instead. The method getFromDialog is used to parse values from the dialog after it has been closed by clicking OK. This method has the code which calls validate method afterwards.
9. Validation code could be optimized. Well, this can be arguable.
So I have found 9 problems. Is that a lot for 20 lines of code? Maybe an eagle-eye professional could add even more. All thoughts are welcome.

So to finalize the first post I strongly believe that the code should look like this:

If you can see any issues with my suggested code, feel free to comment.

Be aware and take care!

2015 m. gegužės 14 d., ketvirtadienis

When Collation Takes Over

Hello AX World,

I once had a very interesting issue worth to share. I have recalled it recently when I wrote a SQL script.
This is specifically for databases with the collation Danish_Norwegian_CI_AS.
Consider these two statements:
The first is valid and the second is not. Why? Because AA and aA is treated differently in this collation.

I was running an upgrade (AX 2009 to AX 2012 CU7) and it failed on source environment, live preprocessing stage. It failed on the script:

After spending some time and analyzing it turned out that the issues was due to the DB collation.

The upgrade framework have registered the script as "smAAgreementLinePreUpgradeProcess" but later it searched for "smaAgreementLinePreUpgradeProcess".
See the difference. AX is case insensitive! How could it happen?

As mentioned earlier, AA and aA is treated differently in in Danish_Norwegian_CI_AS collation. AA is converted to a Danish/Norwegian letteÅ and aA is remains aA, therefore the SQL statement could not find what it searched for.

The issues was resolved by making the registered value and search value equal. 

In particular, I had to change one line in method ReleaseUpdateTransformDB50_SMA.initTransformationJobs when it registered the script.

This a good example that a great developer have to consider much more than just it's code.

Be aware & take care! :)