Is it a good idea to impose uniform code format for all developers?

Herding cats and preserving egos, one standard format at a time.

This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

Java developer Stijn Geukens is working with 10 developers, and nearly every dev has his own style. That's about to change, as the company may soon impose a standard code format upon all developers. They'll be using Eclipse to help facilitate the change. But is forcing consistency upon the team more trouble than it's worth? See the original question here.

How professional

I currently work at a place where a standard code format is enforced and the code is automatically formatted when saving the file, just like you are about to do. As a new member of the company I found that the common formatting rules gave me the feeling that "these guys know what they are doing," which was assuring. In addition to the common formatting rules, we also enforce certain rather strict compiler warning settings in Eclipse, with most set to "Error," many set to "Warning," and almost none set to "Ignore."

I'd say there are two main reasons to enforce a single code format in a project.

First has to do with version control: with everybody formatting the code identically, all changes in the files are guaranteed to be meaningful. No more just adding or removing a space here or there, let alone reformatting an entire file as a "side effect" of actually changing just a line or two.

The second reason is that it kind of takes the programmers' egos out of the equation. With everybody formatting their code the same way, you can no longer as easily tell who has written what. The code becomes more anonymous and common property, so nobody needs to feel uneasy about changing "somebody else's" code.

There are other reasons why a single code format is optimal as well. I find it comforting that I don't have to bother thinking about the code formatting, as Eclipse will do it for me automatically when I save. It's care-free, like writing documents with LaTeX: it's formatted afterwards and you don't have to worry about it while writing. I have also worked on projects where everybody has had their own styles. Then you have to think about trivial issues such as whether it's OK to modify somebody else's code in your own style, or if you should try to imitate their style instead.

The only argument against common code formatting settings that I can think of in your case is that it's an ongoing project, so it will cause numerous unnecessary changes in all the files, messing up the actual file histories. In the best case scenario, you'd start enforcing the consistent format right from the beginning of a project.

Using these should help you avoid arguments about which style to follow. A lot of public libraries and open source projects tend to use these conventions, so when you need to look at those the formatting should be familiar. Also, the Eclipse formatter has built-in rules to match these conventions, which should also help.

You might want to consider building a hook into your source control setup so that code gets auto-formatted before it gets into the main branch.

You can avoid battles with particularly stubborn programmers who refuse to follow the standard. They can even use their own formatting while they work, which will get standardized later! If you end up using custom formatting settings (e.g. a lot of people ignore the "max 80 chars per line" convention) you only have to make changes in one place.

Get everyone involved

I was on a team that used the Checkstyle plugin. Rather than use the out-of-the-box features, we formed a small committee of interested developers. We debated over what seemed missing, what seemed excessive, and hammered things out. We all learned something in the process, and strengthened those developer muscles. (Examples of our decisions: 72 characters wide is too small, but 120 was better; it's better to use _ALLCAPS for static finals; enforcing single-exit from a function is a good idea.)

When we had code reviews, one of the first questions was: "Have you run it through Checkstyle?" Complying with the coding standards was largely automated, and it drew the attention away from the reviewer being picky. It was wonderfully easy to have Checkstyle highlight a method signature, right-click, and change a variable to final. It could also fix the indentations and braces so that everyone's code had a similar look and feel. Missing a Javadoc for a public function? Checkstyle will flag the function. (Removing code smell is more important than consistent formatting. This is a benefit of automated tools.)

I would place automated tools like Checkstyle less as imposing the same format and more on encouraging a similar look and feel. And when you're herding cats, an automated tool can help sharpen skills and reduce code smell without bruising fragile egos.

It makes the most sense to let each developer use the style (s)he is most comfortable with and not store formatting information in version control. You can do essentially that by canonicalizing the formatting upon check-in and formatting according to the developer's preference upon check-out.

As for this:

Quote:

enforcing single-exit from a function is a good idea

Unless you're programming in C or another crippled language that requires routine manual resource cleanup without providing language features to ease the pain, that's a terrible idea.

No one in his right mind would defend a universal language, laws, currency and moral standards. If we take this route to the last consequence we would be defending genetic uniformity.

Having said that, there's value in conventions, standards and norms wherever the restrictions they impose outweigh the inconveniences to creative individuals.

The balance is probably a function of the developers closeness. It makes perfect sense to unify coding standards in the same project. Distant projects probably should have different standards since the "best" coding practice is still hotly debated.

I don't like it, but I do conform my coding style to that of the code base.

Furthermore, if you start new guidelines, I propose getting everyone involved, explaining the benefits, and make a joint decision. Use common sense. If your programmers are smart enough to understand ?:, allow it. Do you fear that one day less skilled people have to maintain the code, make it clear to the current devs that they have to keep that in mind. Because readability is what this is about in the end...

Yes: the benefits from consistency (e.g. clean diffs & fewer bugs caused by confusion) outweigh those from personal preference. As a Python developer, significant whitespace and PEP-8 are great for shutting down potential bikeshed arguments which soak up time and accomplish nothing of value. I really like Go for being even more aggressive and shipping gofmt so there's not even the excuse of requiring too much time.

I now use code cleanliness as a language smell test: I swore off of Perl after realizing that I had to run everything through perltidy and parts were still incurably ugly (e.g. nested data structures). Formatting seems small but it's key to keeping code bases with more than one developer manageable.

At my work we have a few self-inforced standards regarding N spaces per tab, general style rules for each language, etc. These things help greatly in reducing the "huge git diff because someone changed one line" problem.

But automatically enforcing more granular structure in code smells like a problem; not just from an implementation point of view, but instigating style wars as well. It also smells like an attempt to get a big group of Jr devs to write "good" code, or, even worse, make a Sr devs code understandable to the Jr's. Anyone who has spent an afternoon refactoring an old JavaScript project for the sole purpose of getting it to pass a linter knows how much time can be wasted here.

Why not spend this time learning why your coworker implemented something a certain way, or working together to learn something new? If we all become better programmers, then things like code format start to be non-issues.

At my work we have a few self-inforced standards regarding N spaces per tab, general style rules for each language, etc. These things help greatly in reducing the "huge git diff because someone changed one line" problem.

But automatically enforcing more granular structure in code smells like a problem; not just from an implementation point of view, but instigating style wars as well. It also smells like an attempt to get a big group of Jr devs to write "good" code, or, even worse, make a Sr devs code understandable to the Jr's. Anyone who has spent an afternoon refactoring an old JavaScript project for the sole purpose of getting it to pass a linter knows how much time can be wasted here.

Why not spend this time learning why your coworker implemented something a certain way, or working together to learn something new? If we all become better programmers, then things like code format start to be non-issues.

If this is done correctly it requires little effort from developers.

Aside from a few things the formatter can't handle, you should be able to format your code however you want because the formatter will conform it to the company style when you check it in.

I place time spent on how many spaces is a tab right up there with the productivity of diversity training. Who the hell cares? Don't you have product you are worried about getting out the door? Autoformat whatever style you want and ignore whitespace in diffs (if you aren't using COBOL). I can't believe all the crap people spend time on driving up costs. This kind of crap is why large teams don't produce many functional units per developer. Focus is on everything but getting something done.

As a once upon a time project manager I did impose a C standard on my group. I am sure that it helped with getting new people on board. I know it helped me. I am a good coder but lack the brain circuitry that makes other people's code readily meaningful to me. (Seriously, and a very serious deficiency.) A style standard does somewhat ameliorate that problem.

I place time spent on how many spaces is a tab right up there with the productivity of diversity training. Who the hell cares? Don't you have product you are worried about getting out the door? Autoformat whatever style you want and ignore whitespace in diffs (if you aren't using COBOL). I can't believe all the crap people spend time on driving up costs. This kind of crap is why large teams don't produce many functional units per developer. Focus is on everything but getting something done.

You are not considering maintenance which is often more expensive than development and a major factor in customer satisfaction. Just "get it the hell out the door" is a major flaw with today's development environment when maintenance is considered.

I place time spent on how many spaces is a tab right up there with the productivity of diversity training. Who the hell cares? Don't you have product you are worried about getting out the door? Autoformat whatever style you want and ignore whitespace in diffs (if you aren't using COBOL). I can't believe all the crap people spend time on driving up costs. This kind of crap is why large teams don't produce many functional units per developer. Focus is on everything but getting something done.

For the most part I agree: there are no coding standars where I work and everyone is sufficiently knowledgeable to read and respect others' formatting. I don't think there's ever been an issue because of it. But I work for a small company that only hires experienced people and I could see there being problems with juniors that haven't developed proper coding habits or aren't used to seeing others' code.

I place time spent on how many spaces is a tab right up there with the productivity of diversity training. Who the hell cares? Don't you have product you are worried about getting out the door? Autoformat whatever style you want and ignore whitespace in diffs (if you aren't using COBOL). I can't believe all the crap people spend time on driving up costs. This kind of crap is why large teams don't produce many functional units per developer. Focus is on everything but getting something done.

You are not considering maintenance which is often more expensive than development and a major factor in customer satisfaction. Just "get it the hell out the door" is a major flaw with today's development environment when maintenance is considered.

What are you talking about? Maintenance costs aren't closely tied to "uniform code format" but rather "bad code". Uniform format is mainly where people circle jerk about where braces are placed and what gets capitalized. Bad code is where people cut and paste large blocks making a few changes in said block instead of using a function.

Because 80% of the code's life will be spent in maintenance. The cleaner, clearer and more consistent the code base, the easier it is to maintain.

That doesn't mean that you neglect good architecture, design, patterns, code review etc; it is just one of MANY things that developers have learned over the previous few decades that makes code maintenance easier.

I've always liked the idea (as described by others above) of having a program which would automatically reformat the codebase to "my" formatting on checkout and then convert it back to the "team standard" on commit. Over the years we've made a few attempts to get such a thing working with the codebase at work, but there always ends up being a few corner cases which prevent us from adopting this approach.

The codebase in question is approximately 1 million lines of C++ stored in a mercurial repository. 5 developers working on Linux (command line hg), 5 on Windows (TortiseHg).

The first problem is the beautifier - we've tried both bcpp and Artistic Style, but in both cases there were 1 or 2 developers who couldn't get it to convert to "their" format. The second problem was integrating it with TortiseHg - for somereason those guys couldn't get it working with hg encode/decode filters.

It makes the most sense to let each developer use the style (s)he is most comfortable with and not store formatting information in version control. You can do essentially that by canonicalizing the formatting upon check-in and formatting according to the developer's preference upon check-out.

As for this:

Quote:

enforcing single-exit from a function is a good idea

Unless you're programming in C or another crippled language that requires routine manual resource cleanup without providing language features to ease the pain, that's a terrible idea.

It's a good idea, but doing so is tricky. You're going to have at least two styles in your codebase before your team writes its first line of code (standard libraries and platform) and odds are whatever your team wants for a style isn't going to look too much like either of them. Additionally, whatever coding standards your team adopts shouldn't negatively impact the maintainability of code for whoever is likely to be the primary maintainer.

I, personally, strongly prefer my classes organized with types first, data second, and functions third, with members grouped by some logical mechanism (all functions implementing a particular interface grouped together, above in the data section all members associated with those functions grouped together, with however many public/private/protected blocks are necessary to have the desired visibility without breaking up the logical groupings). Reasonable people can and do differ, and there's some argument for, say, putting simple accessors with the data they access for example.

When debugging, I prefer to leverage automatic filters (in VS, local watch and auto) for data as much as possible so I scope very aggressively to try to keep those clean. Auto and inferred return types on lambdas are also things I generally avoid. Reasonable people can and do differ on whether that's best or not.

Mandating a codebase-wide standard on such things is likely to negatively impact someone's productivity somewhere, and I don't believe that a good team would do so, but it also means that whatever standards a team does apply to code will allow pretty significantly different styles to live within the same codebase. To some extent that's healthy, because styles evolve, and you can always learn a better way of doing something. Especially in c++, since c++/11 has added so much new functionality. Compilers are still implementing the standard so the "best" way to do things is actually changing pretty rapidly. Adhering to a common style shouldn't prevent people from adding new tools to their toolbox as they become available.

Absolutely. Reading other people's code is hard. If everyone's code is formatted the same, you can much more easily understand their code. Further, it's just not that hard to conform to one particular style and there's typically no given style that's arguably better. E.g., one can't argue that any of these functions are formatted better than the other:

void my_function(int MyParameter){}

void MyFunction(int my_parameter) {}

void _my_function(int myParamer_) {}

But I guarantee you that if you have your coders always follow the same formatting for how variables and functions are written, that rule all by itself will make your company's code instantly more readable.

Style is incredible important. It is the first step in allowing teams to easily use or understand each other's code. At my company, we code review all of each other's code and we enforce a strict standard on a lengthy style guide. It takes a few months for new employees to start inherently coding in our style, but once they acclimate to it, the fact that they have to code to a given style is 100% a non-issue for them. Because everyone's style is usually just an arbitrary collection of rules that, apart from consistency, don't really matter much.

After people start using the same style, then making them leave grammatically and syntactically well formed comments is also important... but I suppose that's a different topic.

Absolutely. Reading other people's code is hard. If everyone's code is formatted the same, you can much more easily understand their code. Further, it's just not that hard to conform to one particular style and there's typically no given style that's arguably better. E.g., one can't argue that any of these functions are formatted better than the other:

void my_function(int MyParameter){}

void MyFunction(int my_parameter) {}

void _my_function(int myParamer_) {}

But I guarantee you that if you have your coders always follow the same formatting for how variables and functions are written, that rule all by itself will make your company's code instantly more readable.

Style is incredible important. It is the first step in allowing teams to easily use or understand each other's code. At my company, we code review all of each other's code and we enforce a strict standard on a lengthy style guide. It takes a few months for new employees to start inherently coding in our style, but once they acclimate to it, the fact that they have to code to a given style is 100% a non-issue for them. Because everyone's style is usually just an arbitrary collection of rules that, apart from consistency, don't really matter much.

After people start using the same style, then making them leave grammatically and syntactically well formed comments is also important... but I suppose that's a different topic.

I have never ever even a single time had a hard time reading another human's code due to formatting. I suggest that if basic formatting differences are a big problem you probably don't review much code outside your format pure circle.

The problem with standard formatting is often its just an ego trip. There are many ways to format the same code, and often those coming up with the standards will simply force developers to use what makes it easier for them. Just take variable names as an example. Some prefer to identify data type as part of the name (dPrice), some like camel-case format (StockPrice), some like short names (prc), some like long descriptive names(CompanyStockPrice), and some use dashes or underscores (Stock_Price). Some like to define their variables in the beginning of the block, and some like to do it right before they're used. Which way is better? Coding is a creative process, constraining it too much with someone else's 'style' only inhibits it.

I would rather developers concentrated on functionality instead of trying to conform to someone's idea of what looks good. In my company, we have code that has been modified for decades, following half a dozen different styles. It is a bit hard at times, but I never felt like - we need to make placement of braces a standard - we simply adjust. When I work on code that doesn't follow my formatting style, I adjust to match. I think it's actually better this way - I can read code regardless of its formatting style, and make no assumptions. For us, as developers who will likely work for a few companies during our professional career, and who will work on multiple languages and a myriad of coding styles, obsessing too much about a standard formatting choice makes no sense. Flexibility is the key. Over my nearly 2 decades as a developer, I have changed my style probably 4 or 5 times, when I found something that works better (but usually not because someone forced me to).

I think best approach is not specifics (i.e. indent depth, placement of brace, etc) but high-level best practices - such as simply requiring an indent, and having meaningful variable names, and let the rest be on the developer. Once you have that, the rest is fine.

For the record, I'm an OpenEdge ABL developer, and rarely work on Java/C++/.NET, so I don't have a luxury of published / community vetted style guidelines. My opinion is related to general development, not to already existing published guidelines for Java, Android, etc.

E.g., one can't argue that any of these functions are formatted better than the other:

void my_function(int MyParameter){}

void MyFunction(int my_parameter) {}

void _my_function(int myParamer_) {}

My criteria's always readability, and I'd argue that the first form is more readable. Two reasons. First, when dealing with if and while statements where the trailing end of the expression has lots of closing parentheses, having the opening brace on the same line makes it likely it'll get lost in all the similar shapes. Second, having the opening brace on the next line means all blocks are formatted the same whether they're the block after a statement, a function body or a free-standing code block.

Similarly for whitespace, I dislike code styles that elide whitespace between tokens. IMO "if((x+(y-7))==((z*3)/a))" is harder to parse than "if ( ( x + ( y - 7 ) ) == ( ( z * 3 ) / a ) )", especially when variable names are long or tokens are complex enough that you're breaking the expression across multiple lines. The harder it is to parse, the more likely you are to make mistakes (or miss mistakes) in nesting when you go to modify things later. It also means you can set things up so that eg. " end " means a reference to variable "end" and searches for it will never include results for variable "resend" or function "SendLine". I can work around confusions like that, but I hate having to take multiple stabs at regexps to come up with something that finds what I'm looking for and excludes similar stuff I'm not. The faster I can find what I'm looking for, the quicker I get the bug diagnosed and fixed.

The problem with standard formatting is often its just an ego trip. There are many ways to format the same code, and often those coming up with the standards will simply force developers to use what makes it easier for them. Just take variable names as an example. Some prefer to identify data type as part of the name (dPrice), some like camel-case format (StockPrice), some like short names (prc), some like long descriptive names(CompanyStockPrice), and some use dashes or underscores (Stock_Price). Some like to define their variables in the beginning of the block, and some like to do it right before they're used. Which way is better? Coding is a creative process, constraining it too much with someone else's 'style' only inhibits it.

Hilariously enough, I see this is as exactly why coding styles are good. People wanting their own coding style is entirely an ego trip, so just pick one (it doesn't matter which, just pick one- the language's recommended style, some other predefined one, or one the team throws together), end the bike-shedding/messing up the VCS's history with style changes, and focus on the creative process. The 'value' of different coding styles is much, much less than having a consistent code base.

Less memorization, less having to look things up. Anybody can adapt to a new coding style fairly quickly (if they're not trying to be a stick in the mud), so moving to a different organization/project with a different style isn't a problem.

Coding standards increase readability and allow developers to focus on more important things. Considering many languages have plugins/programs to auto-format there is really no excuse. There is no doubt that certain coding practices will irritate you as a developer, but deal with it. My organization requires fully qualified names for XAML, which I find annoying and verbose but it does help considering how insane some XAML can get. As an example of what non-standards do, I personally like lambdas over loops or some recursion but some developers have a very difficult time reading it. But if I must change in the future, I will adapt.

Its not about "a good developer should be able to read other peoples code", but more about why waste the time figuring it out.

I'm firmly in the "just pick one and keep to it"-camp. I got opinions on code style and standard as everybody else, but it doesn't matter that much and consistency is more important than what I happen to prefer.

A code standard does not have to be extremely detailed or enforced to the last white space, but just "braces on the same row, camelcase" etc, whatever they may be. I think mixed code formatting looks very messy and increases the the time it takes to read data structures and code just a little bit when jumping from file to file or class to class while debugging or reading up on a program flow.

Maybe a bit more controversial, but I think one should adapt the style of code on a deeper level to the one in code base as well. Is the code made up of large functions with relatively little abstraction? Do the same. Is it made up of very generalized code with virtual interfaces? Follow the lead. Does it use complex or advanced language features sparsely? Don't use them if you don't really have to. Of course a code base has to be able to evolve with time, but it's i no use of having radically different approaches mixed all over the project. Most approaches has their pros and cons, but If you mix them to much you might loose a lot of the pros and mostly get all of the cons.

A lot of this doesn't seem like it needs to be manually enforced. That just creates a lot of unnecessary baggage that the developer has to think about instead of just programming.

Ideally, we could have each developer's IDE have a list of code-formatting rules. Multiple choices for brace style, indenting, spacing between statements, etc. Once checked into the central repository, it will be stored there according to its own conventions. But most importantly, when checked out, the local developer is working in their own familiar formatting.

Now extend this parser with error checking for disallowed parts of the language: templates, exceptions, user-defined literals, whatever your company decides is too complex for the entire team to be using.

Some things will of course require standards: some styles add additional information that is much harder to add heuristically (Hungarian notation, more descriptive variable names, etc.) And where to place whitespace lines between several lines of code, and when to declare variables, will still be largely in the domain of the individual developer.

But the idea is that the most meaningless syntax preferences, like "foo& const bar" vs "const foo &bar" and K&R vs Allman are trivial things for a parser to translate between.

Code consistency is vital, I'm sure no-one really disagrees with that. But the choice of which standard to use is fraught. So, given that you're going to have to maintain many different code styles over your coding lifetime (sometimes even in the same role - whether its legacy code, or code written by a different team, or code written by a 3rd party), there really is only 1 solution:

Keep code consistent within itself.

ie, that project you're working on, make sure any changes you make are in keeping with the rest of its codebase. Do not apply any standard other than the one that came with the project (you can tell what that standard is because you're looking at it).

Trying to enforce a common standard on everyone is rather pointless all in all. You will have to read all kinds of code standards, and if you insist on only using one you'll end up losing the ability to read any code, as reading strange code is a skill in itself, one that you will have to develop. Its like the time someone demanded we install stylecop on our .net project - which continually threw up thousands of errors on the legacy code, and the 3rd party code, and the library code we had. (and disagreed with the standards checker that resharper used, sigh) so we were in the position that we were always wrong. Which we weren't because that code was quite tidy and well organised. How counter-productive could you get just because of some anally-retentive navel gazing.

I find standards have more important things to deal with - project layout, documentation formats and so on (have you even picked up a new project and had to go searching for where it outputs the binaries to, or spent time figuring it out only to be told there was a readme tucked 3 levels deep in a non-obvious directory?). Coding standards are not so important in the wider view of a maintainable project.

Where are people working that they have these experiences? I've yet to work in a place where unit test coverage was enforced much less coding style. Who do I have to send a resume too? Do they compensate well? I can't afford a pay cut right now...

Argue maybe about whether it should apply per project or to all projects, but yes.

Yes, simply yes.

I agree. In a small dev shop, this isn't needed since most of the developers will be more like an artist who wants to create a perfect painting. In larger teams, it is critical to suck all the individuality from devs so they don't do stupid things that someone else will miss later or use in the wrong way or if it is just a bad idea. Every language has dangerous constructs - EVERY LANGUAGE.

I think the real issue here is that you are using Eclipse. What a peice of crap that is. Get a real editor.Coding standards and formats should be handled automatically at check in regardless of the editor used. If anyone can tell that the code was written by Dev-A and not Dev-Z, then you have a coding standards failure, IMHO.

I've worked in teams from 2 people to 500+ people. Somewhere around 7-10 devs, you need standards. Where I've worked, we used these standards as a way to train less experienced devs on poor style choices and pointed out how writing the same code, just in a different way would be defensive and would force the compiler to find common errors - we didn't want to wait until runtime. Of course, these were for systems where people would die if they failed, so our degree of care was much higher than the average php code monkey crap and "Agile development" crap being put out every 5 hours on the web. I'm shocked at the lack of QA seen daily on many extremely popular web sites. If I worked there, I'd be embarrassed.

BTW, in the end, each team needs to agree on the standards to be used. If someone can't agree (for whatever reason), then he/she/it needs to grow up and play nice or find somewhere else to play. It is a hard talk to have with a sr developer when they refuse to work with the team's standards, but I've had it. A month later, that person had elected to move on over this stuff. Either people are paid to behave as a professional or they aren't. If they aren't paid, then live with what you get. If they are paid, then they should provide the output that the employer desires.

Where are people working that they have these experiences? I've yet to work in a place where unit test coverage was enforced much less coding style. Who do I have to send a resume too? Do they compensate well? I can't afford a pay cut right now...

Software companies. Yes, they get paid more, generally. They'll expect you to be able to find them.

Well, this is 2013, right?Shouldn't it be possible to let the IDE (like ecplise) do the formatting job and let everyone else have their own formatting rules, e.g. you save it gets saved in some common format, you read a file and it gets formatted to your own rules ... everyone happy (including their ego's) ....