question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Could a setting be considered for SA1501/SA1503 to relax on some kind of statements?

See original GitHub issue

Somewhat 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:open
  • Created 7 years ago
  • Reactions:11
  • Comments:13 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
liquidsnkcommented, Dec 20, 2016

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.

1reaction
vweijsterscommented, Dec 19, 2016

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found