You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We used to set the Access = Internal by default on all of our codeunits. However, with the new rule to detect event publishers in these internal codeunits that are not accessible, we had to fix these codeunits by changing the Access modifier to Public. This introduces a risk, that functions (previously without access attribute, so by default Internal in an internal codeunit) would suddenly become exposed.
With AL XML Documentation, we have following settings enabled in VS Code to warn us on 'public' / global procedures that have no documentation.
However, AL XML documentation is slow (and thus often disabled by developers), and cannot be included in the CI / build pipelines.
So it would be great if BC LinterCop could introduce a rule to check global procedures in Public objects carry at least the documentation /// tags. Since BC LinterCop is included as part of our build process, lack of this documentation comment block would show up as warning / error in our pull request.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We used to set the
Access = Internal
by default on all of our codeunits. However, with the new rule to detect event publishers in these internal codeunits that are not accessible, we had to fix these codeunits by changing theAccess
modifier to Public. This introduces a risk, that functions (previously withoutaccess
attribute, so by default Internal in an internal codeunit) would suddenly become exposed.With AL XML Documentation, we have following settings enabled in VS Code to warn us on 'public' / global procedures that have no documentation.
However, AL XML documentation is slow (and thus often disabled by developers), and cannot be included in the CI / build pipelines.
So it would be great if BC LinterCop could introduce a rule to check global procedures in Public objects carry at least the documentation
///
tags. Since BC LinterCop is included as part of our build process, lack of this documentation comment block would show up as warning / error in our pull request.Some inspiration : https://github.com/365businessdev/vscode-alxmldocumentation/blob/dd62ab5e111ecd3a16d61b52e4b69f19b046164d/src/util/Configuration.ts
Beta Was this translation helpful? Give feedback.
All reactions