AL Business Central Visual Studio Code

Tip: Text constants in AL

Long time no see, but that’s how it gets every now and then, I guess… Anyway, I am still alive, still kicking, just don’t get to blog as much as I’d hope for, it’s work, and life and universe and everything.

So, I am back with not a typical “Vjeko” post, just a simple AL opinion piece. A tip, without a trick.

One of the problems we’ve all suffered from in the old days of C/AL (who remembers that still, anyway) was inability to define real text constants. One thing we all avoided was using hardcoded Text literals, like this:

It was not only about the sheer scariness of using Text literals in C/AL, stuff that if left unchecked could cause process issues, something nobody in the ERP world (especially those on the business end of it) likes. Arguably, the worst thing about this kind of code was total lack of reusability. If you had to reuse the literal, you would have to write it again:

Yeah, the mismatch (or typo, whatever you prefer) is intentional to prove my point. You could mistype it, or somebody may decide to change it and then forget to change it in all places, or… stuff happens, you know. It was no good.

There were no constants, and it sucked.

Yeah, yeah, there *were* TextConst constants, but that’s not it. The moment you did this:

… somebody could come in and “fix” it like this:

And there was no way for you to prevent them. There goes your discoverable extension, things break up and your users start yelling your way.

Back in those pre-historic days, I’ve seen people work around this problem like this:

The “constant” is coded in one place, other place call the wrapper function, and world goes on. That was the way to do it in C/AL, truly.

Fast forward back to present. I’ve got myself in the middle of refactoring a chunk of code migrated from C/AL to AL a while ago. It’s full of “pluggable” things that identify themselves to various discoverers, and it’s full of “constants” coded with this function-that-returns-a-hardcoded-literal pattern.

While this worked miracles in C/AL, in AL we actually have a far better way to handle this. Labels. Yeah, fells like I am discovering hot water or sliced bread or something, but please, for the record, don’t do this:

Instead, do this:

If you set the Locked property to true, you are making sure nobody inadvertently translates it, and you keep it a bit cleaner. This is especially true if you have multiple constants – listing them in your var block will be much cleaner than creating a function a piece.

Here endeth the lesson. No rocket science, just an easy one to document my train of thoughts for posterity. Everyone is entitled to my opinion, after all 😁

3 thoughts on “Tip: Text constants in AL”

  1. Ooops, just declared an GetId function yesterday 😁. To my defense I had the tought “In the future this is going to be a part of a setup table and then I only have one place to change. Put I get your point. More easily to find all these “hardcoded values” (constants) at one place

  2. “And there was no way for you to prevent them”.
    I always use: Language=”@@@”, Value = “{Locked}”
    Seems to be the way Microsoft does this in the standard C/AL code…

Leave a Reply