Could a setting be considered for SA1501/SA1503 to relax on some kind of statements?
See original GitHub issueSomewhat related to #1175 our team uses something in the lines of the following rule to account for common guards:
When the body of an if statement consists of a single jump statement (e.g. return, throw, break, continue) we allow that statement without braces and on the same line.
Which would mean that the initial code on that linked issue will be valid for us:
if (condition) return;
But not so other kinds of statements like:
if (condition) someVariable = "someValue";
if (condition) someMethod();
or even
if (condition)
someMethod();
if (condition)
return;
We feel this is terse and removes clutter without causing readability concerns since the situation is pretty clear with jump statements which break the flow of execution (basically it allows us to have multiple one-liner guards, taking less space).
// Just some example, maybe not the best.
if (obj == null) throw new ArgumentNullException("obj");
if (obj.Whatever == null) return;
foreach (var item in obj.Whatever.List)
{
if (!item.Condition) continue;
Process(item);
}
Now, I know that it’s impossible to account for every team particular requirement or nuance and that maybe this is not even in the spirit of StyleCop at all (cannot say, while we feel we follow common sense standards, we have never adopted the tool until we discovered this great version using analyzers) but having the option to allow these kind of statement while also enforcing the already existing related restrictions is something that will be very good for us.
I imagined that before going and doing our own thing to enforce it or change the way we work to accomodate, it wouldn’t hurt asking the project and the community if they would be interested in considering this behavior as optional or maybe even allow it as a contribution.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:11
- Comments:13 (7 by maintainers)
Top GitHub Comments
Thanks for the thoughtful discussion guys. As mentioned, we only allow this for if statements with jumps as their single child, and we do like the current validations for both SA1501 and SA1503 enabled to happen on other cases than these.
I also agree that those seem to be the options at play here and of course our answers would be “yes” and “current line”, but were you to decide to go forward with this I’m not imagining any other way than having these as settings affecting the two rules, which I realize seems rather specific.
Thanks for the well written proposal. I see benefit in this (narrow) case so a 👍 from me. This will have to be optional, with the default behavior to remain the same as it is now.
The statement on the same line is paramount here, as it reduces the chance of somebody typing a next statement and assuming that it will be executed as part of the if statement. This could be further strengthened by demanding an empty line, but that should probably be a new rule.