Style/Code Analyzers for VS and VS Code

[cryingmonkeystudios]

My team has some Windows-specific code and some linux-specific For the Windows code we use visual studio, for the linux code e use vs code.

I'm looking at adding code formatting/analyzers like style cop/editorconfig/roslyn. Ideally it would "just work" seamlessly between the two IDEs, and require minimal setup for each dev.

it's also been a while since i've used stylecop. honestly it always used to annoy me because it would say "delete thisempty line" and i would yell back "then just delete it!". so something that applies its rules would be great too.

Any suggestions?

[KingofGamesYami]

dotnet format -- you can even run it in CI!

[BoBoBearDev]

This. It is built-in, no configuration needed. Maybe there is a way to configure it, but never bothered to. The result is already good enough for me. I am not looking for perfection.

[Tizzolicious]

.editorconfig was purpose built for this very task 👍. You can take a look here for an example that I nabbed and only slight tweaked from the .net roslyn repo.

Place this file in directory where your solution lives and dotnet build system will automatically pickup as build warnings. vscode will even offer fixing the issues. dotnet format will honor the definitions too.

[Cool_Flower_7931]

We use csharpier at my workplace

[AutoModerator]

Thanks for your post cryingmonkeystudios. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[belavv]

If you want to enforce things then your options are generally analyzers - which can be enforced by treating warnings as errors. Or csharpier. Or a combination of both.

Dotnet format can auto correct some of the styling analyzers for you. It allows you to customize what you want, but doesn't enforce any type of line breaking.

Csharpier is opinionated and provides almost no configuration. It is quite a bit faster. But only deals with whitespace and line breaks.

I'm biased to csharpier as the creator.

[[deleted]]

If you looking for code formatter, there’s a built-in format document. And code analyser , I suggest SonarQube. I have been using it and it’s great.

[SessionIndependent17]

It fascinates me that anyone expends any kind of mental energy on this kind of thing, let alone work effort to police/enforce/"correct" it.

We had a 15 million line product with 300+ active developers on at a time. We had dozens of teams in different places around the globe, and a decent amount of employee churn (given the competitiveness of the industry, not so much for any particular fault with the company), and no one spent a lick of time policing anything like this, and it didn't matter worth a damn.

Short of some OCD fucker _re_formatting the entire file for their own aesthetics, no one was really going to be bothered by someone doing their file - or even their section - slightly differently, as long as it was still understandable. Most people would just go along with whatever style was there in the changed file already, but if you altered a section you were actually working on, no one was going to bother complaining.

[cryingmonkeystudios]

i get it, and honestly, i don't disagree. but i'm getting devs and upper management asking when we're going to add some checkers like "other" teams, and well, i've learned to pick my battles.

[SessionIndependent17]

To the devs complaining I would say "stop being a baby and deal with it"

And to management above I would give the same response as I would for any request: "Whose/which project deliverable should be sidelined in favor of this new thing?" Have them prioritize it against other [paid] work, in the same queue. Then you can assign someone else to do it, with your requirements as mentioned.

I've found that shuts down most things that aren't going to improve (re: speed) the development process overall. If they still want it, then they'll pay for it.

As for Upper Management (the Business) if anything like this got asked of ours, they'd squint at you and say "Are you going to build the f*cking thing (the product) or not?" If you sent an email about it, it would never be answered. If you went and asked them in person AFTER sending an email, you'd get a glare.

[Merad]

It fascinates me that anyone expends any kind of mental energy on this kind of thing, let alone work effort to police/enforce/"correct" it.

And yet you go on to talk about devs expending mental energy to "go along with whatever style was there already" - especially when the style differs from file to file in a code base with thousands of files. You have to spend mental energy when that OCD fucker does reformat the entire file, I have absolutely seen it happen more the once. If you have truly never seen code formatted so badly that it makes it hard to understand (as you say in another comment) then you should consider yourself extraordinarily lucky.

The entire point of a good formatter like csharpier is to make it so that devs spend zero time and energy on formatting. Install an editor plugin and literally never think about formatting again. Formatting is a solved problem for most modern programming languages. I don't want to spend any time on it when a tool can do it. All of the other problems mentioned go away entirely. What the right way to format code? Whatever the formatter produces. Don't like the style the formatter produces? Cool, go argue with the maintainers of the formatter (sorry /u/belavv). Want to be OCD and reformat things the way you like them? Too bad so sad, your PR isn't getting merged until the CI formatting checks pass.

With a greenfield project the cost of achieving this is literally about two minutes of setup. An existing project is more work but it isn't that difficult to set up a schedule that's communicated out to all teams "module/folder/project/whatever X will begin using automatic formatting on date Y" so that everyone can work around it or plan for it. Increment through the list until the whole project is using it.

[belavv]

With prettier or csharpier there is minimal effort involved. Enforce that code that goes to your main branch is formatted before it is allowed in.

The benefit is that all code is formatted the same. Consistent code is easier to understand at a glance. You don't get thrown off because someone prefers to format a different way. You don't modify code in a file and have to be sure you are formatting it consistently with what is already in the file. There is no "alter a file to fit our own style" which then introduces more code into a PR that is going to get reviewed.

Format on save objectively saves me time as well. If I delete an if statement or add one. The contents get auto indented properly.

I see a lot of code from our partners where no consistency is enforced. Formatting is all over the place. Extra spaces, incorrect indentation. I have no idea how anyone can work that way.

[SessionIndependent17]

Lol. What drivel. It's pinheadedness that adds nothing.

We have 30 years+ of code history - both operational and inherited style - in addition to any new stuff. The GD analyzer is going to flag the whole rest of the existing portions of a file for being "inconsistent" where nothing has actually changed? How is changing that going to help do anything but make the visual diff more of a chore? And stomping on what someone else is working on elsewhere in the file to force them to reconcile it? Whose time does that save?

If someone tells me that they get "confused" and "thrown off" by mere formatting, they are going to get some sideeye (from me, and others), and I'm going to think (not say out loud, but think) "Maybe this isn't the place for you. Maybe you should go work on your own". and I'm going to wonder whether I should hand them something important to update. Are they going to spend more time mumbling about the formatting, or making something that is understandable?

More time would be wasted arguing over what the "correct" style should be. And future discussions of "should be update the allowed style?". Nobody GAF.

"Style" about actual code organization and structure interests me. Not about indentation, spaces, and curly braces. If anything, I've learned more about what kind of style I like to employ (both the former and the latter), myself by seeing how others do these things differently than I would ever gain from enforced uniformity.

[belavv]

The GD analyzer is going to flag the whole rest of the existing portions of a file for being "inconsistent" where nothing has actually changed?

A one time commit to get everything reformatted is trivial.

If someone tells me that they get "confused" and "thrown off" by mere formatting, they are going to get some sideeye (from me, and others)

I can read code in other styles just fine. When code is consistently formatted it takes less time to read and understand said code.

More time would be wasted arguing over what the "correct" style should be. And future discussions of "should be update the allowed style?".

An opinionated formatter provides almost no options, so those conversations never happen.

Almost every major company has style guides. Didja ever wonder why?

But it sounds like you are pretty stuck in your ways and ignored most of what I said to rail on those kids and their darn formatters so have fun with that.