Closed jwikman closed 1 month ago
I added the exceptions that are currently in the rule for empty statements that cause a difference in behaviour (that i could find):
if Customer.Get('10000') then;
avoids a possible runtime error opposed to Customer.Get('10000');
, and an empty case line avoids the else-case.
I think allowing other empty statements with a comment sounds reasonable, my main intent of the rule was to find excess semicolons from typos / leftovers from refactoring, and those would probably never be commented. It might even make sense to require the comment instead of the currently existing exceptions, since those can look a bit confusing at first sight without any comment.
I agree, make the comment an exception instead of those special cases. The special cases probably deserve a comment. 👍
(btw, added a new rule suggestion for mandatory else
in all case of
: https://github.com/StefanMaron/BusinessCentral.LinterCop/discussions/748)
@ans-bar-bm, thanks for fixing this! It seems to work great!
Now I got 48 empty statements to go through and comment or modify! 🙂
I think I understand the intent of LC0069, but we get this in a few places where I would consider it a false positive
In our company, we do require an
else
statement on all ourcase
statements (that could be a new rule? 😅). And if there are nothing to do in theelse
part, we still require theelse
with an empty statement together with a comment.I suggest that exceptions for LC0069 are added, so that an empty statement is allowed if it is commented. I now see that similar thoughts are included in the discussion that resulted in this rule (https://github.com/StefanMaron/BusinessCentral.LinterCop/discussions/716#discussioncomment-10197633)
Thoughts?