Coding standards

rsaritzky
rsaritzky Member Posts: 469
in NAV Three Tier
Hi all,

I'm interested if anyone has either read any coding standard documentation (I've checked the NAV coding guidelines), found any references in any "Clean Code" documents, training, videos or blogs, etc. to state that either one of the following examples is "better". Certainly one is more "compact", but in a more complicated function, my interest is (a) debuggability and (b) readability:

Example 1 (this is in a function that in turn calls a function that returns a result TRUE or FALSE):
IF Item.IsAHomeInstallationKit THEN
  EXIT(TRUE);
EXIT(FALSE);

vs. writing it this way:
EXIT(Item.IsAHomeInstallationKit);

While the second option is more "compact", if I wanted to see the actual return value of the called function, I may not be able to trap for it.

The first option, although a few lines more of code, makes it easier to debug and trap for the value during debugging.

Now, this is a very simple example, but it illustrates what my question is - is there an established development standard one way or the other? Are there any references to that standard that you can point me to?

Thanks

Ron
Ron

Answers

  • DenSter
    DenSter Member Posts: 8,307
    Ask 5 developers and you get 5 different answers, to a large degree this is totally subjective. For instance, I can't stand the one in your first example, it feels to me that it is missing ELSE. I find myself going the second example more these days. I never used to think about putting logic into reusable bits of code but that's almost at the front of my mind now.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • Wisa123
    Wisa123 Member Posts: 309
    Hi,

    There is no real "better" or "worse" in this case. However:
    I and many others strongly prefer the 
    EXIT(Item.IsAHomeInstallationKit);

    - Shorter Syntax
    - Makes it so your function has a single Exit - Statement, which is often desirable for readability and understanding
    - The debugger should not be a reason to write your code a certain way (I mean during DEV thats fine, but not in production). Debugging Tools may and will change, your code probably won't.
    - It's more expressive: if we want to return whether an Item is something, Exit(Item.IsSomething()) is the most expressive way to do so.

    On a sidenote (and I know thats also a matter of personal preference) I would always make sure to actually use Paranthesis for readability. The AL formatter does this, in pretty much every other Language it is mandatory and it just makes sense imo.
    Exit(Item.IsSomething())
    Austrian NAV/BC Dev
  • rsaritzky
    rsaritzky Member Posts: 469
    Good explanation, but for me, both the ability to debug and "be expressive" (i.e. readable) is important. I also agree that we are somewhat limited by the current debugger - that you can't see the result of a function call. You can verify the value in code, e.g.

    IF Item.IsSomething() = <somevalue> THEN...

    But unless you store the result or have code to evaluate it, you can't "see" the value.

    I'm a bit older than many developers here, so I come from the days of mainframe languages like COBOL and "structured programming" techniques (and the lack of debuggers), so to me, "readable" means something a bit different. But I appreciate the opinions.

    Ron
    Ron

Categories