When breaking long lines, break line after semicolon

[kieronlanning]

When using fluent methods, it's often advantageous to continue chaining. Especially during experimentation/ organic changes.

Input:

builder
  .AddProject<Projects.Web>("web")
  .WaitFor(worker)
  .WithReference(database)
  .WithReference(blobStorage)
;

Output:

builder
  .AddProject<Projects.Web>("web")
  .WaitFor(worker)
  .WithReference(database)
  .WithReference(blobStorage);

Expected behavior:

builder
  .AddProject<Projects.Web>("web")
  .WaitFor(worker)
  .WithReference(database)
  .WithReference(blobStorage)
;

As an example, if I comment out the .WithReference(blobStorage); I need to place the ; on a newline manually, where-as if it was already broken out this would not be an issue.

[belav]

This is an interesting proposal that I think I'm on board with, but I'm not sure how the broader community will feel. When I have time I'm going to see if this was proposed to prettier at any point. I think it fits with trailing commas and the closing ) of invocations being on their own line.

Another benefit to it - when a new invocation is added to the end of the chain only a single line shows up in the diff, vs right now because the semicolon needs to be removed from the line above.

Do you mind splitting the second part into a new issue? I'm only on my phone for the rest of the week. That feels like a bug to me, commenting a line in the middle of the same chain does keep the line breaks.

[kieronlanning]

No worries, I've edited this one and split the re-formatting issue into a different one.

[Hona]

This isn't a change I'm a massive fan of, we now increase the SLOC by a reasonable amount with tonnes of trailing semicolons on separate lines.

Imagine query heavy/LINQ/EF files. I get the nicer diffs, but I do feel the current format is more C# feeling.

[kieronlanning]

Imagine query heavy/LINQ/EF files. I get the nicer diffs, but I do feel the current format is more C# feeling.

I think the query heavy LINQ/EF is the exact use case for this.

It's actually already the format we adopted company-wide prior to considering CSharpier.

[viniciuschiele]

To me, the only valid reason to increase the SLOC is if it improves code readability. After all, we spend most of our time reading code.

[kieronlanning]

I've struggled with some of the responses here.

I think I've understood the arguments - and I understand them all. I don't agree, but that's ok - we're all allowed to disagree.

CSharpier isn't made to manage an efficient SLOC, it's designed for human readability. So I'm not convinced that SLOC is a valid argument, specifically.

Arguably the SLOC would regularly be inflated.

If you care about SLOC then an opinionated formatter like this isn't a good fit for your project.

Either way. I trust the steerage of this project to come up with a sensible, agreed upon, consistent approach for all of the rules they chose to implement.

[loraderon]

I'm against it.

I have never seen that kind of formatting and a single semicolon on a line gives me the creeps. It looks like it left there by mistake and I would assume it should be removed.

I kinda see the reason if it's a lot och fluent lines so maybe it could only be applied if there are more than 5 or 6 lines? There are other parts of csharpier that has "magic number changes logic" so it's not impossible.

[viniciuschiele]

It's not about SLOC, as you said, CSharpier is designed for human readability. In my opinion, adding an extra line just for a ; doesn't make the code more readable and still increases the SLOC as a side effect.

[kieronlanning]

I'd respectfully disagree that it makes it less readable. In my view it makes things substantially more readable - especially during diff scenarios - MR/ PR.

Is this a rare case of allowing configuration for such a setting?

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity and was not assigned a label or milestone. Leave a comment if this still needs to be addressed or this will be closed in 7 days.