Having standards, even suboptimal ones, is usually better than not having any standard.
Languages, compilers, IDEs, templates, and so on should all enforce consistent standards by default.
The Rust language has rustfmt and clippy. Javascript has eslint and prettier.
I'm a C# guy, so that is what I care about. For .NET we do have StyleCop analyzers. And EditorConfig exists to help at the IDE level across all languages. And git itself can be configured with such things as eol and autoclrf.
But StyleCop is not on by default, and not enforced by default. A default EditorConfig configuration is not automatically applied by default when generating project templates, either via Visual Studio or "dotnet new".
Someone already went through the trouble of producing a editorconfig dotfile that conforms to the StyleCop rules, and yet it isn't even suggested to be applied by any important C# tool. Which is a glaring oversight as bad as when default gitignore files were not suggested by default, leading to countless repos cluttered with bin and obj folders.
The concept of Semantic Diffs may finally be starting to take off, and that will eventually go a long way to improve things when it comes to diffs.
But messy diffs are not the only reason to want code to be consistent. It is also crucial for readability, and even for ensuring that the program logic is explicit. If it is mandatory to qualify instance members, as StyleCop's rules recommend, that helps make things explicit. Yet, the de facto community conventions in C# are the opposite of the guidelines.
Future versions of Visual Studio, OmniSharp, Roslyn, and the dotnet CLI should be taking this to heart going forward, and begin to enforce all of this by default for new projects.
But the best thing you can do is to keep your own home tidy, by ensuring that you turn on StyleCop analyzers, enforce them in your pipeline, and include a strict editorconfig dotfile.
Top comments (0)