Directions Diary - DEV Session - Developing to standards

Finally the session where many developers, mibuso-ers, DUG-ers, ... Have been looking forward to. Why? Well, there has been a post in mibuso where Michael explained that he was going to give some tips & tricks on development standards - with 6.0 in the back of our heads.

They warned us that a lot of the stuff they will be explaining does not correspond to what is currently in the standard database. They're still working on it. So that's why they disclaimed: "Don't do what we do, do what we say". Good one .

(As I don't want to miss any tip/trick/rule/... while typing a "nice" story, I expect this to become a bullet-point-kind-of-post .)

Kim started off by comparing the software design of NAV to Danish architecture and art. I didn't get much out of that, but the main idea was that NAV has to be "Powerfully simple" - That's makes it highly productive.

Actually, it comes down to being well architected, keep a high partner and user productivity ... . With well architected, they mean:

• Re-usable
• Intuitive
• Recognition
• easy to maintain
• rich & consistent use of patterns
• low concept count
• layered and modular
• as few code lines as possible
• design to be customizable
• minimal/no localization needed.

Those are strong concepts isn't it? I have my questions about the localization though... . I know for Belgium, it's quite a big localisation. Spain, Italy, ... as well. It would be nice to be able to easily merge localisations into databases... . Anyway ...

Kim also tried to explain the "Philosophy of Dynamics NAV", and this is something where (in my opinion!) many developers go wrong. The NAV application should be intuitive through familiarity and patterns. Very important in my opinion. If you have to develop something that doesn't exist: just look for available standards (journal, worksheets, ledger entry, posting codeunits, ...) and try to make it the same look&feel as the entire standard application.

Here comes Michael with the rules:

1. Don't break the basic concepts.
   1. Repect the purpose: a journal is a journal, don't let it do things not expected by a draft
   2. Logic for a table, belongs on a table!
2. Don't re-invent the wheel
   1. Let NAV deal with: transactions, error handling, resources
   2. Be true to the data types
      1. string is not a byte array. This is important for version 6, because there, a string won't be an array of bytes, but unicode... .
   3. Use the code patterns that all ready exists in NAV (Copy paste, not waste)
3. Don't assume everything is intentional
   1. Don't make use of side-effects in C/AL

      FOR I = 1 to 10 BEGIN ... END;

      What is the value of "I" now?? Not the same for C++ as C/AL!

   2. Don't build code expecting a certain order of code execution
   3. Don't use default as a flag (undefined = blank in NAV, but what does it really mean?).

   Michael demo-ed a peace of code like this:

   MyStr[3] = 'C';

   MESSAGE(MyStr);

   MyStr[2] = 'B';

   MESSAGE(MyStr);

   MyStr[1] = 'A';

   MESSAGE(MyStr);

   Only the last message showed the string 'ABC', the other messages were EMTPY. He showed also other pieces of code like an IF-statement with an OR-clause. IF funcA or funcB behaves differently then IF funcB or funcA . It all comes down on the fact that you (as the title mentions) should not assume something, but create clear code.

4. Use general good practices
   1. Use multi language texts instead of text constants in the code
   2. Avoid global variables
   3. Use local flag on functions unless explicitly needed to be global
   4. Support standard functaionality
      1. Dimensions
      2. Navigate
      3. Look up & drill down
      4. Change log etc.
5. Use terminology actively: Good terminology and naming conventions is half of the solution.
6. Be Lazy (Don't overcomplate it)
   1. Write as little code as possible
      1. Use properties, relations, lookups, etc.
      2. Use standard functionality
      3. Reconsider using it, if it is unusual, like:
         1. LOCKTABLE(TRUE,TRUE)
         2. COMMIT
         3. COUNT
         4. RecRef: don't abuse this, only use when necessary.
         5. Recursion
         6. Code on OnLookUp

The, the "Evolution of C/SIDE". The Role based client compiles C/AL code int C#. It uses native.net datatypes. It runs on a managed rewrite of the C/AL function library on a separate tier (the service tier).

These are the obsolete methods, so you shoudn't be using this anymore.

• COMMANDLINE
• ENVIRON
• OSVERSION
• SHELL
• CONTEXTURL
• VARIABLEACTIVE
• WINDOWSLANGUAGE
• CODECOVERAGELOG
• QUERYREPLACE
• YIELD
• BEEP
• Dialog.Input
• ... (there were many many other functions on form, report, ... level - but that went to fast to write down )

Some of the system tables are also obsolete:

• Server Table
• Code Coverage
• Ole CONTROL
• Automation Server
• Printer

For the C/AL Language, strings can only be indexed between 1 and Length + 1.So, if S := 'ABC', then S[4]='D' is valid, but S='E' is not... . This is again the string being unicode in 6.0, not array-based ... .

That was it - I hope this was useful for you. I did my best to get as much out of it as possible for you. I know that, somewhere on partnersource, there is a document that describes what you should take into account to prepare your code for 6.0. I will post the link as soon as I find it.