-
-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistently Indent By 4 Spaces #617
Comments
Getting csharpier to work with EditorConfig formatting is not currently a goal. If it required just a couple of changes, I could see doing it, but I did a test with just a basic EditorConfig like this
Which resulted in all of these changes in the current set of test files After looking at editorconfig-checker, it sounds like it only supports checking basic formatting, which could be accomplished with If you are using an editorconfig to enforce non-formatting rules, you can use dotnet format to apply the fixes and validate nothing else needs to change see https://github.com/belav/csharpier/blob/master/Docs/IntegratingWithLinters.md#dotnet-format with the |
I think we might be discussing subtly different things. EditorConfig itself is not an auto-formatting tool, so the non-trivial diff you linked must have been generated by something else (possibly Visual Studio 2022's on-save automated code cleanups?). I totally agree that compatibility with whatever tool generated those changes shouldn't be a goal of CSharpier. I'm only talking about compatibility with editorconfig-checker, which doesn't automatically format anything, and is a far less ambitious goal. This one issue is the only incompatibility between the two in our entire code base. I do think that regardless of all of this, mixing indentation sizes detracts slightly from the developer experience, because it makes it harder to write code in the style of CSharpier. Not only is the mixing a difficult rule to remember, but it's also not likely to be an available editor setting without the creation of many CSharpier editor plugins. The result is code that is harder to read until the next time I run CSharpier, by which point many developers won't be going back to read it anyways (not that I advocate that, ha ha). Disabling EditorConfig (for C# only, but continuing to use it for other languages) and using Having tried ReSharper's CleanupCode, |
Yup, I realize my mistake now. I am ashamed to admit I haven't used an editorconfig before. I went from stylecop to prettier to building csharpier. I made the assumption that I needed to format all of the files (with rider + an editorconfig in this case), then compare them to what csharpier output. Really I just needed to run editorconfig-checker on files that csharpier has already formatted and see what it complains about. I can check that out and see what it will take to get them aligned. The mixed indentation came from prettier, but I don't think there is a strong reason to keep it.
I started using csharpier format on save a while ago, and I can't go back now. I spend almost no time on formatting code beyond line breaks and just save to let CSharpier fix everything for me. There are plugins now for rider, VS and vscode. And a file watcher can work for any other editors, although it is a bit slower.
If you use Husky.net it's possible to run dotnet-format just on the files that were changed. See this example. Unless you are already doing that and dotnet-format is still slow...
You are very welcome! |
Yep, that all sounds right to me. Prettier is such a great tool. They list their community plugins on their website. I hope they would be open to mentioning CSharpier in some capacity. Whenever you feel like it's a good time for your project to attract some publicity, I'm happy to open a pull request (possibly to this file?) to add CSharpier to their list of mentioned projects. We wound up adding EditorConfig initially to help deal with variation in editors and settings and eventually also to get rid of those pesky UTF-8 BOMs Visual Studio so loves since we are working cross-platform. Every now and then I discover some new use of it though.
Woah, that is super impressive for such a young project. Sharing the good news with my team and installing some plugins now. Good point about a file watcher too.
More woah. Thanks for the tip; we wound up going with pre-commit after trying Husky, but I completely missed Husky.net. I just double-checked, and MegaLinter (which we also run via pre-commit) already runs dotnet-format on only the files that were changed. Part of the problem is that we are making a lot of sweeping changes to our code base, so that optimization only gets us so far. |
That would be awesome. I think it is ready to start trying to attract some more attention. I actually added csharpier to https://prettier.io/docs/en/related-projects.html a couple months ago, but having it on their homepage would be nice. I have a more realistic look now at what would need to change to get csharpier to conform to Besides conditionals there are also SwitchExpressions, ConstraintClauses, and BaseTypes |
Apologies for the delay; just got back from a trip.
I've opened prettier/prettier#12428; fingers crossed!
That makes sense. My teammate accidentally discovered another benefit of making this change at this point. As I understand it, the CSharpier VSCode extension works best when |
As a side note, it would probably be useful to add support for CSharpier to obtain some configuration from an |
That probably deserves its own issue. I think a minimum viable support of EditorConfig would be to use |
#346 doesn't work great with EditorConfig. For C#, one typically sets
indent_size = 4
. When using editorconfig-checker however, one has to setindent_size = 2
to avoid throwing errors on nested ternary statements, for example. That then causes the editor to tab 2 spaces rather than 4, largely defeating the purpose of specifying anindent_size
in the first place. It seems simpler to expect folks who want less indentation not to put an inordinate amount of code in a single statement than to use 4-space indentation 99% of the time and 2-space indentation 1% of the time. I'm positive there are other tooling scenarios that are affected by the 1%.The text was updated successfully, but these errors were encountered: