-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The name of TableName is not valid. The name of variables and parameters must be suffixed with the type or object name.AL(AA0072) #6120
Comments
Same would go for suffixes if they are also only used to mark fields as belonging to a co./app. |
Agree with dtkb - we use suffixes for AppSource. Suddenly we've got hundreds of suggestions that our variable names aren't valid 😱 |
Two more problems with this CodeCop: 1) Problem in [EventSubscriber] procedure 2) Problem if object name contains dot |
How to correct name two variables the same record? Above that temporary? |
It sounds like this feature was just nowhere near ready enough to be released. I bet running it over the standard codebase, which for better or worse is a fairly good predictor of a lot of end-user code out there, would have noisy enough results to make that clear. Even after the bugs were fixed and convenience features added, how could we reconcile this with the typical idiom of abbreviating |
I asked the same question about abbreviations a few months ago, but without an answer. A similar question was if I had a Record variable (such as Customer) once as local, the second as global: it must not be named the same, but both must have the suffix TableName. Will we introduce the (previously rejected) prefixes Loc... and Glob...? |
Not having Prefix and Suffix in the name should be allowed. EventSubcriber error is a bug as well. We are working on the Temp issue. Not allowing abbreviations are by design. We had a big internal discussion and landed on no abbreviations. Not allowing 2 vars like customer1 and customer2 is also a bug. Thanks for all the good feedbask. |
I'm curious about whether Microsoft will also update the base app to apply to this rule. The reason I'm addressing this is because reports need to be copied to our own extensions to be customized. To apply to this rule we would now have to update the variable names in the copied report. When the report is updated later on in the base app, we would in many cases also like to update our copied report(s) which is an easier task when all variable names match. It's good to hear that the Temp issue is worked on, I agree to the comment of @AskeHolst about the readability. Is it also possible to allow both 'Buffer' and 'Temp' for temporary records? |
@MarcHansenMicrosoft thanks for the feedback. I'm curious though why MS feel the need to dictate any rules at all on this? I've got a few concerns:
I know I can just disable this rule but I'm interested why we've got it at all. |
I totally agree with @jimmymcp . Just one more thought (sorry if already mentioned somewhere): |
It will be only Temp for now. We will not force this rule for BaseApp only System and other extension. For copied reports I would pragma ignore the specific rule. I see all of your points in the abbreviations but for now we do not plan to change it. First we will focus on the bugs. |
I see there have been some new threads started, but I'm surprised there hasn't been a comment here in a month. I'll be the first to say that I am all for standards and nudging, sometimes forcing, developers in the direction of improving code quality. I absolutely love the majority of the rules. Unfortunately I feel that this one is forcing a reduction in quality. I have to imagine the reason that there isn't a "Suggested Fix" for the warning is that Microsoft does not have the ability to define what "Readable" code actually is. The only fix that would work every time would make the code so unreadable it would destroy the intended results. So we're left with the developer making yet another choice on readability. Does anyone else see the irony here? Variable naming is a standard, not a rule. We'll continue to educate developers on the standards for properly naming their variables, and they will adapt specific situations to write working code that is still readable. No one can put a firm rule on what readable code is. It's subjective. I haven't seen a rash of unreadable code lately, so unfortunately this is probably going to fall into the ever increasing set of ignores. Could someone from Microsoft explain what root problem was occurring and why this was the solution? My mind could definitely be changed. |
Some more issues:
|
same with InStr and OutStr |
I am using a suffix 'G' for global variables. For 2 reasons: 1. make a distinction between a local var like Customer, and a global var Customer, and 2. to make very clear to any programmer that a suffix 'G' stands for global var (I only use the Hungarian notation for this case). |
"Not having Prefix and Suffix in the name should be allowed." Please finalize this role ASAP. Abbreviations allowed yes/no. Prefixes/suffixes mandatory yes/no. Object name as suffix yes/no. Reserved words yes/no. Numbers in variable names yes/no. Disable in subscriber parameters. Thanks. |
To revisit my comments from last week, I am glad that this rule is in there as an option. That said, I think we've pretty much gotten to where we are going to add this to our ignore file and the more I think about it the more I think we might not ever take it out. It's been this way for a while, and I do at least partly understand why, but the idea that these rules are not enforced in the main codebase just doesn't feel right to me. I get that every company has to make its own decisions about what quality means to them and what to prioritize. At the same time, combined with the suggestion to pragma ignore the warnings when copying from a base report instead of fixing them? And the insufficient testing before this rule was released? To me that just shows that this isn't a serious issue for Microsoft, and thus not a serious issue for me. |
Is there a reason this rule is case sensitive? Nothing else in AL is... |
Hi everyone, some changes were made to AA0072: @IvoMol |
Thanks @dan-cris , from which AL Language version on is it available? |
@NKarolak it should be available in the latest developer preview . I will close this issue as it is diverging from the original. If you still have issues after trying the developer preview please make another issue and report it there 😀 |
Describe the bug
Could this warning Ignore the Prefix of the Object please? It's just incredibly ugly to add the prefix to ObjectNames.
To Reproduce
Steps and to reproduce the behavior:
Add variables with a Prefix:
AL Code to reproduce the issue
Expected behavior
Don't trigger the warning if only the prefix is missing
Screenshots
If applicable, add screenshots to help explain your problem.
5. Versions:
The text was updated successfully, but these errors were encountered: