Text constant in C\AL Locals. Is it already allowed?

Maria-S

Hi all,

Recently I reviewed the code from our partner and noticed that they put the text constant into the C\AL Locals section instead of making it global.
In time when I was young and silly developer, we were prohibited to make the text constants local

However, I did not found any mentioning of such restriction in the documentation. Furthermore, the documentation says it is OK to create local text constants


"You define text constants in the C/AL Globals or C/AL Locals window."
https://msdn.microsoft.com/en-us/library/dd354917.aspx

Can anybody show me the piece of documentation where the best practice of NOT creating local text constants is described?


I am starting to think maybe our partner made OK. Also, I cannot imagine any reasons for the restriction :-k

Thank you!

Luc_VanDyck

I know one reason for making all text constants global: It's much easier to find out where a partical message is used in the code when you can lookup the name of the text contstant globally. Otherwise you need to search in every function.

Dan_K

Microsoft's coding guidelines state that all text constants should be global: https://community.dynamics.com/nav/w/de ... -constants

Personally, I prefer to limit the scope of all variables... as well as the benefits of encapsulation, it also makes the C/AL Symbol Menu easier to navigate.

Kowa

Maria-S wrote:

Furthermore, the documentation says it is OK to create local text constants

Not anymore, these should be avoided. See page 15 in the coding guidelines here:
http://blogs.msdn.com/b/nav/archive/2015/01/09/c-al-coding-guidelines-used-at-microsoft-development-center-copenhagen.aspx

mohana_cse06

If we use same text constant in many places in different functions then we create global text constants otherwise we prefer to create local text constants which will help us in merging some fixes or development and we don't get any compilation issues because we may forget or don't know which global text constants should be merged etc.
if they are local then we don't have to think and there will be no compilation errros

BardurKnudsen

A small comment to the MS NAV internal coding guideline regarding not using local text constants: I think we all prefer local variables; also text constants. However, we have a practical issue in that our translation tool currently only picks up the global text constants, hence the (internal) rule about only using global text constants.

Maria-S

Thank you guys very much!

Our partners are from India, so I think they have the same reasons as Mohana said: simplier merging and fixes.

For me placing text constant into local variables is unusual, but seems it make sense after all.

I also checked the translation tool that we use, it seems it is OK with local text constants, so let partners do as they used to.

Best Regards,

Mariya