[Question] - Can an empty class format be skipped without applying the 'ignore comment'? See image example

[jeffward01]

Hello all!

After reading the configuration document - I do not think this is possible, but I still wanted to ask.

The goal is:

• I do not want empty classes to be formatted. (It causes issues for some Code Generation tools I have)
• I do not want to apply the // csharpier-ignore to each empty class
• I would like to add a value in a configuration file to tell csharpier to skip this format

Is this currently possible? (I know csharpier has no plans for future configuration options)

Thanks!

[belav]

It is not currently possible to configure, but I have been considering changing the formatting of empty blocks.

There are times where I create an empty method and as I think about what I want to put in the method I hit ctrl-s. That formats the method to a single line and screws with my cursor placement.

Empty blocks don't really occur that often in real code so I don't think the extra lines will really cause any headaches.

Out of curiosity, what code generation tools are you using that have issues with the collapsed blocks? I'm debating between these too, and would lean towards the first one assuming it works with the code generation tools and solves the problem I have.

class ClassName
{
}

class ClassName
{

}

[Meligy]

If I'm not mistaken, there are editoconfig settings for these brackets, like csharp_new_line_before_open_brace.

https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/code-style-rule-options

It would be good for the tool to respect relevant editorconfig rules in general.

[belav]

@Meligy if CSharpier respected editorconfig rules it would essentially be allowing configuration. There are no plans to allow any configuration beyond the current limited set of options. There is a backlog issue for reading the supported configuration from an editorconfig.

[Pentadome]

personally, i hope u dont change this

[jeffward01]

personally, i hope u dont change this

@Pentadome - Why is this? It could perhaps be a flag such as --csharp_new_line_before_open_brace which would create classes like:

class ClassName
{

}

@belav - I also respect that this is venturing into the territory of opening a can of worms, where the developer could say:

Well, one rule XYZ from .editorconfigis respected, lets add 2 more.. then 10 more, actually, lets use the.editorconfig as a possible source of truth.

It would be cool, but I do understand that this opens the potential for deeper change which is not quiet in the spirit of csharpier, although there is a backlog for it.

Just wanted to say big thanks for the library @belav <3

[gat-cs]

@belav, my 2 cents, as somebody who recently started using csharpier and is very much enjoying it. I greatly appreciate that there are no options, and would very much like the editorconfig can of worms to remain shut.

Empty blocks don't really occur that often in real code so I don't think the extra lines will really cause any headaches.

There are use cases for empty methods and classes. I am not saying all the examples below are good ideas, but there are not so unusual to see in the wild.

• using classes or interfaces as "marker" for a bit of extra type safety:

class Message { }

// then use as a constraint
class SomeContainer<TMessage> where TMessage : Message
{
    // or
    void DoSomething<TMessage>(TMessage) where TMessage : Message
}

// define the message
class MyMessage : Message
{
    /* some stuff here */
}

• inheriting classes just to differentiate them

class MyClass : BaseClass { }
class NotQuiteMyClass : BaseClass { }

• extending multiple interfaces

interface IMyInterface : IFoo, IBar { }

• making a class or interface non-generic

interface IInterfaceOfMyClass : IFoo<MyClass> { }
class MyDerivedClass : BaseClass<MyClass> { }

• overriding a virtual method, or implementing an interface method with a no-op

override void TheMethod() { }

C# is already a language that takes a lot of vertical space. The ratio of useful code lines (not empty or just a bracket) to total lines is not very high.

// 1 line - with meaninful content
class Message { }

// 3 lines - 66% of the lines are blank - but still fairly compact
class Message
{
}

// 4 lines - 75% of the lines are blank - please avoid that
class Message
{

}

---

Regarding the inconvenience of the cursor ending up in the wrong place with saving an empty class when you intend to edit it further: you can add // to the body and csharpier will keep the brackets on separate lines.

public class ClassName
{
    //    <- temporary
}

---

Regarding code generation tools, what is the problem exactly? Is it (1) that the codegen tool malfunctions when the code was formatted by csharpier, or (2) that it outputs code that is not formatted the csharpier way?

If it is (1), then it feels wrong to change csharpier output for everyone because some codegen tool is buggy. Also, as pointed out, csharpier offers various ways to ignore code or entire files (https://csharpier.com/docs/Ignore) that should be sufficient to ignore those files.

If it is (2), the solution is to run csharpier after the codegen tool.

---

Once again, thanks for csharpier :)

[domn1995]

Just wanted to chime in that the current format really disrupts stubbing out classes and methods. I run into this more often than I expected, so I support changing the empty body formatting to be

class-or-method-declaration
{
}

[belav]

I did a quick version of these changes in #763 as a way to see what kind of affect this would have on some codebases.

One thing I ran into was if empty lambdas should also include a new line. I left them with a new line to see some better real world code that would be affected.

private static readonly Action _callbackCompleted = () => { };
// vs what is currently in the PR
private static readonly Action _callbackCompleted = () => {
};

Running this across all of csharpier-repos affected at least 5,000 (github won't show the real count past 5k) of the 71,000 files. The review page for the PR just crashes. My next step is figuring out a way to review these changes, either splitting apart the PR into smaller chunks or seeing if I can review it locally somehow.

For what it's worth, prettier seems somewhat inconsistent about empty blocks and I couldn't find any discussion about it.

if (true) {
} else {
}

function Method() {}

class Class {}

while (true) {}

for (var x = 1; x < 2; x++) {}

[jeffward01]

Thank you for checking this out, thats alot of changes, I agree with what you did with the lambda, also - it makes it look more like a 'method' rather than a property, which for me is easier to read that it has function, its not just a delegate, its an invoked method action that performs 'work' on something.

I agree with your decisions! really cool work!

[belav]

I got this running against the aspnetcore portion of csharpier-repos.

I don't think formatting empty lambdas with a line break is a good change. It results in things like the following.

builder.AddJwtBearer(jwtBearerScheme, o => { });

// becomes

builder.AddJwtBearer(
    jwtBearerScheme,
    o =>
    {
    }
);

builder.AddOpenIdConnect(openIdConnectScheme, null, o => { });
builder.AddCookie(cookieScheme, null, o => { });

// becomes 

builder.AddOpenIdConnect(
    openIdConnectScheme,
    null,
    o =>
    {
    }
);
builder.AddCookie(
    cookieScheme,
    null,
    o =>
    {
    }
);

When excluding empty lambdas, ~17% of the files in aspnetcore are modified. That's quite a bit more than I was expecting.

Thinking about it more, I think CSharpier should be focused on formatting to a state that is most readable. I don't think that adding a line break to an empty block makes it more readable.
The empty block collapsing when stubbing out methods and saving them before filling it in can be annoying, but maybe the plugins can do a better job of keeping the cursor inside of the block. Everyone that uses the plugin learning to add // to them temporarily isn't ideal, but is the other solution.
@jeffward01 I'm also curious about the code generation tools that have issues with the collapsed empty blocks. Maybe they can be modified to work with the collapsed blocks?