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
Today, we are struggling with the IndentationCheck rule in legacy code using preprocessor directives. For readability, we put statements that only apply for TTY (or not) with 1 extra tab. But this violates the IndentationCheck rule.
Example below:
Do you see a possibility to enhance this? I guess the file is preprocessed for SonarLint analysis? Maybe if the rule could be configured to check the non-preprocessed code and ignore preprocessed blocks?
The text was updated successfully, but these errors were encountered:
There's also #1060 where preprocessor is involved. Dealing correctly with that is quite difficult for multiple reasons:
The preprocessor silently discards tokens from the stream if the &IF condition evaluates to false (the parser just doesn't see those tokens)
No extra info is (currently) added to the tokens that have been preprocessed, so the parser and then the rules doesn't have any knowledge of the preprocessor
Just thinking out loud, but it may be possible to keep the number of nested levels of &if into the tokens, and use this information when executing the rule. If two statements are in the same block but in a different preprocessor block, then the issue could be skipped. This behavior would be controlled by an attribute in the quality profile. The algorithm would have to be changed on how to compute the "base" position, but it's probably doable.
gquerret
transferred this issue from Riverside-Software/sonar-openedge
Dec 22, 2023
Hello,
Today, we are struggling with the IndentationCheck rule in legacy code using preprocessor directives. For readability, we put statements that only apply for TTY (or not) with 1 extra tab. But this violates the IndentationCheck rule.
Example below:
Do you see a possibility to enhance this? I guess the file is preprocessed for SonarLint analysis? Maybe if the rule could be configured to check the non-preprocessed code and ignore preprocessed blocks?
The text was updated successfully, but these errors were encountered: