Menu
If it is possible to auto-format code before and after a source control commit, checkout, diff, etc. does a company really need a standard code style?
It feels like standard coding style debates that have been raging since programming began like "put the bracket on the following line" or "properly indent your (" are no longer essential.
I realize in languages where white space matters the diff will have to consider it but for languages where the style is a personal preference is there really a need to worry about it anymore?
358
Automatic formatting enables higher code quality, especially when you are collaborating in a team and other people need to look at the code you've written. Many developers and organisations maintain standards of code formatting like 2-space or 4-space indentation.
Code style is like the music during a dramatic scene in a movie: if you notice it then it's a problem. Good style makes reading code a pleasurable and consistent experience. However, having to follow a style guide can feel far less than pleasurable.
Use the dart format command to replace the whitespace in your program with formatting that follows Dart guidelines. This is the same formatting that you can get when using an IDE or editor that has Dart support. For more information about this and other dart commands, see the Dart command-line tool page.
Enables auto formatting of the code when you save a file. Visual Studio supports auto formatting of the code with the CTRL+E,D or CTRL+E,F key shortcuts but with this extension the command 'Format Document' is executed on Save. Thanks Karen ! The Code Formatter is a 3rd party Visual Studio plugin.
Yes, it's a good idea. Projects generally have coding style guidelines to reduce the chances of this being a problem. These can range from very loose to very strict. Guidelines include, but are not limited to layout and formatting.
Proper and continuous code formatting is essential for readable code, but these conventions can be cumbersome if you have to do them manually. But the good news is that VS Code editor has numerous code formatters that can make it easier and faster to write readable code.
That’s why VS Code allows you to utilize auto-formatting extensions that can help you along the way. Some auto-formatting extensions can format more than one programming language, while you’ll need to integrate specialized extensions for others. Hyper Text Markup Language or HTML is a coding language used to build and display web pages.
Auto-format can really only address whitespace.
It wont address developers giving variables bizarre nonsensical names. It won't address some developers having functions return null on an error vs throwing an exception.
I'm sure others can think of more examples.
183
This is what we do at my work:
We all use Eclipse. We don't have a policy for using Eclipse but somehow none of us is an IDEA/IntelliJ guy. We also think our code should be written with legacy in mind. This means our code has to be readable in a certain way even years after (#1) no matter who wrote it and if that person even is in the company anymore.
Eclipse has couple handy features, automatic format on save and a specific Formatter tool. As you can see from the linked screenshot, it can be configured with XML. Thus there's a bunch of premade XML:s available for every worker in our company so that when a new guy comes in, we walk him through of the whole process and configure their Eclipse for them (yes, it's slightly evil thing to do) so that it actually uses those formatting XML:s we have provided. We do not enforce automatic format on save, we don't want to be completely intrusive, we just want to push all our developers into the right directions. For even increased compatability, we mostly use rules defined in JCC.
Next comes the important part, the actual builds. We are those who embrace automatic builds and for that we use Hudson Continuous Integration Server. There's two important parts in our configurations beyond this:
The Checkstyle Plugin is the magician in our code style enforcement guide line:
Basically this means that when anyone commits ugly code into our CVS, our build server automatically reduces that person's points.
This means that eventually any one of us can be ranked on the Leaderboard based on the general code quality in both look and OO principles such as Law of Demeter, Cyclomatic complexity etc. etc. Naturally this isn't a completely serious statistic, but it's a good indication you're doing something wrong when causing a build to be initiated in our CI won't reduce your points - most of our commits are worth between 1 and 5 points.
And is it working? Sort of, I don't think anyone of us at my work writes ugly or unmaintainable code and personally I love to hunt all kinds of scores so it's definitely motivating me to make code that looks nice and follows all the OO paradigms I know of.
And do we as a company really need it? I think we do as you should see from reading this entire answer, it can be considered a good practice for the advancements it brings.
#1: in a related note, I refactored legacy code from 2002 today which used those standards, didn't look "bad" at all even in its original form and certainly not worse in its new form
3
No, not really.
If you can actually get it to work consistently and not make it flag code has changed due to a different style of laying the code out.
However, this is just a small part of coding standards. It won't cover multiple return statements, the use or not of ternary operators, etc.
2
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
