Skip to content
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

LC0010: the cyclomatic complexity of CASE statements #566

Open
Pazzakara opened this issue Mar 18, 2024 · 1 comment
Open

LC0010: the cyclomatic complexity of CASE statements #566

Pazzakara opened this issue Mar 18, 2024 · 1 comment
Labels
question Further information is requested

Comments

@Pazzakara
Copy link

I really like the LC0010 (check Cyclomatic Complexity/Maintainability Index) because it always reminds me to write simple and short functions.
But as soon as I have to make a distinction between enum values, I have to violate this rule.
Example: an enum has 10 possible values. Depending on the option, something different should happen.
The simplest/least complex way to program this is:

local procedure CheckOption(MyEnum: Enum "My Enum")
begin
case MyEnum of
MyEnum::Value1:
DoOption1();
MyEnum::Value2:
DoOption2();
MyEnum::Value3:
DoOption3();
...
MyEnum::Value10:
DoOption10();
end;
end;

but this function will raise a LC0010 anyway (cyclomatic complexity >= 8). But there is no posibility to do this less complex.

I would like to suggest that a case statement increases the cyclomatic complexity only by 1, no matter how many option values are queried. BTW: this is the only way to get an advantage from case statements compared to querying the options with 10 if-then statements.

If you think this change would contravene the definition of cyclomatic complexity too much, I would like to ask if my suggestion can be added as an optional setting, so that I can activate it via the extension settings.

@Arthurvdv
Copy link
Collaborator

I completely understand your request and also I've stumbled upon this to be honest. Applying a case statement with different enum values will indeed quite easily hit the cyclomatic complexity threshold of the LC0010 rule. I'm not on expert on the calculation of the cyclomatic complexity, where I'm unsure if changing the behavior of the rule is the right approach for resolving this.

Ideally we should replace a CASE statement with Enums and Interfaces to achieve extensibility and improve code maintainability.

Cognitive Complexity
In the future maybe we can add Cognitive Complexity to the LinterCop as an alternative: #285. An example of the differences between the both of them:

image
https://www.sonarsource.com/blog/cognitive-complexity-because-testability-understandability/

@Arthurvdv Arthurvdv added the question Further information is requested label Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants