Slashdot Mirror
Does Coding Style Matter?
theodp writes "Over at Smashing Magazine, Nicholas C. Zakas makes the case for Why Coding Style Matters. 'Coding style guides are an important part of writing code as a professional,' Zakas concludes. 'Whether you're writing JavaScript or CSS or any other language, deciding how your code should look is an important part of overall code quality. If you don't already have a style guide for your team or project, it's worth the time to start one.' So, how are coding style guidelines working (or not) in your world?"
At my workplace, we just all plug the same code style settings into our IDEs, and everyone's code gets formatted the same way automatically. And yes, it matters: having everyone's code formatted the same way makes it much easier to read.
Of course coding style fucking matters. Code's generally going to be part of a much larger product that existed long before you joined a company and will continue to exist long after. You don't want the codebase turned into some sort of elaborate puzzle with 200 different methods of laying out code contained within. Uniformity makes maintenance much easier.
I've always preferred to use tabs over spaces for indentation, 2 breaks in between major sections or functions, and clearly named vars or functions. The kind of code most people can drop into and say "Oh, I see where this is going" and immediately begin to understand and therefore modify.
I can't stand opening up any type of code, even web pages, and finding ugly difficult-to-follow lines which seemingly make no sense. Then again, it's all a matter of preference and perspective, isn't it?
What else can happen when an unstoppable force collides with an immovable object?
The thing I dislike most about discussions of coding style is that since the topic of coding style has an extremely low barrier of entry, everyone has an opinion. I know bad code when I see it, I could give a fuck how many spaces are in a tab or how many characters to a line.
Learn one word: consistency.
Be consistent from one piece of code to the next, from one project to the next. Be consistent about your design ideas, be consistent in your thinking. It's going to help you and anybody else working on the same stuff.
Everything else is sugar.
You can't handle the truth.
I do not see any point in coding styles whatsoever. All they do is slow down coding for all but the two guys that actually like the coding style as defined; for the rest it's needless busy-work to comply.
I agree that one persons code should look consistent; so someone should pick a style and stick with it. Also if I am making a SMALL change in someone else's code, I try to mimick the style of code around it.
It's so easy to run a code formatter on something now that someone else can read code however they like if it's really important. But while code is underway conformance to a specific style is not helpful.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
clearly readable code is the first step toward getting it accepted.
Get a program to refactor the code into whatever style you want. I'm amazed people still have make this an issue.
Mine is best, yours sucks to the extent that it isn't mine and most editor/IDE authors are too lazy to make mediating style a critical feature; but they seem to be slowly getting there. Now get those goddam spaces out of my indents so I don't have to get carpal tunnel, or else make me an editor smart enough to automaticly import them as tabs and export them as spaces so that we can just. stop. talking. about it.
There are no shortage of automated systems perfectically capable of (re)formatting code. For this reason personal choices with regards to tabstops, bracing, spacing and general layout simply does not matter.
As far as non-decorative conventions and comments..consistency obviously generally helpful.
I do believe there is diminishing returns on overdoing it with added danger of folks not being able to function effectivly in environments where code is produced by other groups outside your administrative control using different conventions.
In short try to be consistent but never make a decision which presums either yourself or others have been consistent.
Ctrl+K, Ctrl+F
Presto, you've got your coding style for code that you didn't write.
It totally depends on your audience. Is this code something that must be read by one person or a hundred? If its one other person, it probably doesn't matter unless they have strong feelings. If its 100 people then you should have a standard template so people don't waste time arguing. Personally, I know that my code will be read during a code review of about 5 people. I need to make sure that all of those 5 people are comfortable reading it. For example, I happen to be working in C# and some of my co-workers hate the var type declaration, so I don't use it. Some of them have strong feelings about always using braces, so I do. At the end of the day, as long as your code is easily understandable the minutia of style guides are just to keep other people from getting their knickers in a twist. That can be far more important than whatever code you are working on.
Dont invent your own style guide, use one from a book. Like Clean Code.
This prevents discussion and new team members might already know the rules when they join in.
Python Reference Manual: 2.1.8 Indentation: Leading whitespace (spaces and tabs) at the beginning of a logical line is used to compute the indentation level of the line, which in turn is used to determine the grouping of statements. First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-blank character then determines the line's indentation. Indentation cannot be split over multiple physical lines using backslashes; the whitespace up to the first backslash determines the indentation.
In my opinion, it depends. For a single person coding and making some program (doesn't even have to be in a company) and not planning on putting on sourceforge or something, it probably doesn't matter. In a company where code is shared and debugged between lots of people, yes it does. So all in all, formatting probably does matter in the long run.
This isn't the sort of thing anyone really disagrees with. It is more of a learning article, or a "I have expertise in this field and here is proof" article, than anything really worth discussing on its own merits. Even the inevitable tabs vs spaces, same line vs next line bracket discussions have little merit: In a large organization/community - its best to stick to published guidelines for a given language.
I don't really care how you *format* your code. Do you put the brackets on the same line as the beginning statement? Do you put a space between the function name and parentheses? Do you double-space your code? I don't give a fuck. That's all syntax. It's easy to figure out.
Coding style is more important to me, how the actual *code* works. Do you initialize your variables as soon as possible? Do you properly use for loops and while loops? If you use recursion, does it make sense? Do you give your variables meaningful names like $activityType, or useless ones like $_a? How do you decide when to break something out into a function?
I work on a project with several other people. We all have our unique styles, both for format and for code. I, for instance, have been told I code with a "LISP accent", rarely storing the return values of a function in a variable, rather using the return value as an argument to another function. Another puts a blank line between nearly any two statements. Another assiduously follows some code formatting standard nobody else in the company has read.
Although it can make it harder to work on each other's code, it has one benefit - you can easily tell who wrote the code. "Putting the braces on a new line? This must be Pete's code!" or "There's an underscore at the front of every variable name? This must be Jimmy's code!" or "There's a for loop that starts ''for (;;){''? This must be Kevin's code!".
And if I do go in to "someone else's code" and change or fix things, I follow their style, more or less. Unless I'm completely rewriting a section, or making enough of a change that it should be considered a rewrite.
When working with code written by more than one person you need rules. It helps with code review and helps new people intergrate into the project more easily. The larger the program and the more people involved the more stringent they have to be.
Of course many of the rules can be applied by the IDE/editor or post processed this is fine as long as submitted code is up to speck. It's genrally better to do it right from the beginning though.
The precise rules themselves don't make much diffrence as long as they are sensible. Consitency is key.
Most Damage is done by people who are AWAKE
1. Use spaces instead of tabs.
2. Make your code readable by humans.
Consistency is nice, but comments are way better. I could care less if someone uses spaces or tabs between shit, as long as it has comments about what the code is doing or trying to do, I'm happy. Well, was happy, I don't really code anymore.
Be seeing you...
The best article that I've ever read on coding style is Style is Substance by Ken Arnold.
I won't repeat what he has to say here, because he explains it better than I could. But I wish that more programming languages would follow what he is advocating, because we waste way too much time arguing about braces and tabs.
Nice to be reminded of these ideas. While they come up most prominently in our early years as software developers, we tend after a decade or two either to take them for granted (should we be so fortunate as to work in a place where everyone writes clean code as a matter of course) or perhaps to give up on them in despair (when working in a code maintenance regime that puts a priority on generating minimal diffs where the code base is - and must perpetually remain - an ugly steaming mess.)
The practice of software development entails in the same undertaking aspects of style, design, engineering, and science. On that spectrum, the stylistic element can seem relatively trivial, subsumed into the others. Okay, fine. What that really means is that when we encounter stylistic failings and inconsistencies, we're bound to wonder what else is wrong with the code. Style, in other words, communicates something about care and attention in general.
As a form of communication, it's interesting to consider the Japanese tea ceremony. Few human activities are so completely formalized. Its essential form is pure simplicity, where every action in every detail of movement can be given full attention. Every tea practitioner knows this form intimately. What's interesting is that this form, while aesthetically pleasing, is seldom followed exactly. It functions sort of like a carrier wave. How a tea practitioner departs from form encodes the signal, superimposed on the carrier. In feudal days, the encoded aspect was critical. It provided a way for people to communicate on subjects that were politically dangerous.
In writing software, we're probably not concerning ourselves with political intrigue. But still, how we express an idea in code provides important information. Consistency of form is reassuring, whereas departures from form draw our attention. We're bound to ask "why did he do it this way over here but this other way over there?" In good code, the reason should be evident. We should feel a small kick of satisfaction that we're inside the mind of the programmer, that we're on the same groove.
It's the kind of code we should all aspire to write. Style is not mere decorative flourish. If it is, something is wrong, because form follows function, and this would be form without function.
Parity: What to do when the weekend comes.
Just use Artistic Style for C and its derivatives C++, C#, and Java. I usually set it for "--style=ansi", but that's a project preference. External code is run through Artistic Style before use. This way, everyone knows the indentation is consistent.
For Python, of course, there are few formatting options, so this isn't an issue. Dreamweaver will indent HTML. Javascript remains a problem.
Almost all the posted comments are talking about formatting (tabs vs spaces, indentation, line breaks, etc).
While its good to be consistent with these. Style is so much more.
Consistant naming schemes for variables/functions/classes/methods etc.
Useful and meaningful comments.
Handling non-expected input and states gracefully
Catching and handling of exceptions
meaningful feedback to the user if there is a problem.
I would call all these things and more "style." These are the things that make it easy to maintain code after it is written. They also help to reduce the incidence of bugs.
In my experience, "messy code" is a good indicator of "messy development". I strongly believe that the structure and appearance of the code is a insight into the developer's brain. And messy code: Usually means trouble ahead.
And yes: IDEs can help with automatically formatting code: It's good since it allows developers to spot obvious mistakes, and it's bad because it allows bad developers to hide structural errors. But probably good overall.
There's more to coding style than simply indentation: The really most important concept is clarity.
If a developer cannot explain (in one sentence) what a given function does, what a given class does or what a application does: be worried. If the developers thinks they know and still cannot explain: Be very worried.
There are best practices and rules a programmer should follow and those should be set at the team level...call that "style" if you want. But formatting? Who cares? The IDE takes care of that. If the diff engine on your IDE or repository can't tell the difference between code changes and whitespace changes then something's wrong. I was on a (Java) project where half the team liked braces on a new line and half didn't. When I worked on code written by someone else, the first thing I'd do is hit alt-shift-F (Netbeans) to reformat the code. I'd do the same if I pasted some code...reformat the file to get the new code formatted the right way.
Our SVN repository wasn't glutted with meaningless diffs and I didn't face hundreds of conflicts when updating code. In this modern age (despite the lack of flying cars) it's silly to have to conform to one standard to make the software happy. Software works for us, not the other way around. I use software to format code the way I'm most comfortable with...why should everyone compromise so no one is happy? Just set up your tools properly and stop worrying about formatting.
My does:
My don'ts list is getting shorter and shorter. Most programmers have reasons why they produce the code the way they do. Lack of experience should be met with understanding and appreciation for improvements.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Yes. Allman style is the best style.
People complain about all those empty lines with just 1 bracket on them, but whatever, for me it just makes the start and end of a scope clear.
One of my least fofourite has to be GNU style.
I don't know how the fuck stallman came up with the braindead idea to put the braces halfway between the previous and current indent level, but it drives me crazy.
I promise if your team is kicking around coding style conventions you might not be doing important work. Be careful. This might be a clue you're replaceable. If your doing creative work nobody asks about coding style. They only ask, is it new, cool, and ready to ship. Respectfully, Jim
When writing code everything matters.
Forcing people to follow a style I think is counter productive. It prevents the styles from evolving. In recent years for example people have been moving towards using better naming rather than commenting.
Strict rules prevent creativity and for that reason I disagree with the conclusions of the article to require one. Requiring anything more than just to follow a style no matter what that style may be and to try to maintain the existing code in the style that it was in is about as much as you can do.
"The best way to predict the future is to invent it." - Alan Kay
then you have never worked on a free software collaborative project; you have never submitted patches to free software projects; you have never worked for a large software engineering firm with ISO9001 (Software TickIT) practices in place;
I have worked with large engineering firms; I have not have submitted small patches to OS projects long ago but as I noted, for small changes I mimic existing coding style.
I have worked with dozens of teams ranging in size from two to thirty or so.
in fact you have probably never worked with revision control tools ever in your life.
I have worked with many such tools starting with RCS, then CVS, then git.
running a code formatter and then creating a patch automatically includes your modifications in amongst a bunch of whitespace modifications,
You may have not noticed where I said small changes I mimic existing coding style. I am talking about new code, where someone who is submitting the code is also the guy who has been writing it for a while. As long as the people working on that block of code are consistent, there is no SCM issue with them coding as they like. I am not saying to re-format a whole file and check that in; just to make it more readable as needed.
bottom line is: i'm not impressed.
And I am sad you cannot read, nor understand the point I am making.
Hopefully for the good of future teams you can eventually lodge the stick out of your ass that companies have made you push in so far you don't even know you have it any longer.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm a stickler for consistent styling as well as formatting. It's one of the reasons I like .Net so much - they have a nice code analysis engine built into their build system as well as a decent style engine that can be added on. There's a bit of adjustment when the source control system rejects non-compliant code, but once you start learning what the guidelines are, it gets easier to write it properly the first time. The base framework itself is reasonly conformant to those guidelines, so more effort can be placed towards effectively interfacing with the libraries.
And it's interesting that almost every place I have worked *wants* to use MS formatting/style guidelines; it's just rare for the boss actually pulls the trigger on enforcing it (inevitably, the argument goes towards "yeah, but how much of an effort will it be to make all of our existing code conform?"). Fortunately, I am currently on a .0 product version that entails a rewrite, the question of making existing code compliant is a non-starter.
Format your code so that the coders can read it.
If your'e on your own, format how you like.
If you're on someone else's project, format how they like.
The compiler truly does not give a rat's behind about it, so approach it as a people issue.
And that means being prepared to capitulate if someone else in charge wants things done their way.
The compiler doesn't care how you format the code.
Your boss, however, might.
When I think of coding style I think of the following: Methods shall not be over 40 lines long. Files may not over 1000 lines long. If blocks must not be nested more than twice in same method. Do not use the else command. Do not use Ternary operator "?:" Do not nest loops more than twice in the same method.
Yes, next question?
-- This space for lease, low setup fee, inquire within!
Who modded the parent down?! To me the parent actually was insightful. Anyone have positive mod points to spare for the AC?
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Or perhaps he really meant deep-seeded since the words describe something.
This is also a forum, and you wasted moments of your life trying to correct someone on something other than improper spelling and grammar. You've corrected their meanings....
-- This space for lease, low setup fee, inquire within!
Python is a fever-dream...
-- This space for lease, low setup fee, inquire within!
That "anal retentive asshole" is making everyone's job easier - including yours.
I have never found the anal-rentiive to make anything easier overall.
Because human minds see patterns, and they decipher familiar patterns quicker and more accurately.
Exactly why letting people code as they wish is not a problem, as long as each coder is consistent. When you open any given module, it's all consistent and your brain latches on to the patterns in use quickly.
So when everybody's code looks the same, it's much easier for other coders to maintain
I'm confused: Does the human mind see patterns or not?
Of course, you probably didn't bother to think about that, now did you?
Far more than you will ever know.
Letting people code in a style closer to what they prefer reduces errors going in. Perhaps you love finding errors later; I do not. I'd rather they never go in. But perhaps you did not think about that... now did you?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
More important than using your own code style is using the language code style if there is one. For example in C# you should code in the same style as the .NET, in Java like the Java SDK and in Objective-C (on OS X/iOS) like the Cocoa APIs. Don't invent your own style if there is already one existing.
When someone other than you controls what code gets published, you buckle down and do what the fuck he tells you.
And that includes kowtowing to their preferences on coding style.
So if you're coding on someone else's turf, do what the fuck you are told.
Arguing over coding style just seems to be part of the software development mentality. It was going on 30 years ago when I first started in computers, and it will no doubt outlive me easily. In management, when you are looking for something to do, you call a meeting. In software development, idle time can always be easily eaten up by starting a discussion/debate/argument over where to put the lousy curly brace or parenthesis.
Yes, yes, coding styles are more than just indentation and such, but in the end it has always seemed to me to be about a few things:
1) Is the code readable?
2) Is the code consistent?
3) If the code is not how I would have written it, are items #1 and #2 above being observed?
If a piece of code passes all three tests, then I suggest that there is nothing wrong with the coding style. This opinion may not be the latest rage on the software lecturing circuit...but it has proven to work just fine across 30 years of development, countless problem domains, and project teams ranging in size from 2 people to 500+ people.
I personally hate coding styles, a coding style gets in the way of producing code. If someone wants my code formatted in a certain way then they should format it when they get it. Almost all commercial IDE's and Text Editors can format code at the click of a button so if someone really wants my code formatted they should set up the rules and do it themselves, after all if the argument is they can't click a button then it's not my fault.
I came here expecting endless threads of coding style religious wars. I was not disappointed.
I like to wear a black Versace cocktail dress accessorized with fire engine red Prada fuck-me pumps when I code. It makes the occasion special.
Vertical space is very important. I agree that breaking submodules out with v-spacing is as important as using braces to collect a group of actions together. The braces tell the compiler that the group may be viewn as a single object. The spacing/vertical spacing of lines tell the coder that the segment is a disctinct sub-object or module inside a group of code items.
.
When you've got to be able to de-cipher and re-jigger someone elses code to get the job done, a stable and well-defined coding style means that the job really can get done in a finite amount of time.
Code formatting can be a religious issue (I have my favorite style) and just like this article says probably often stems back to trying to please some forgotten professor. Often there is a logic behind each style rule. But mostly I agree that there should be one true style at any given company. In a weird way it might be good to have a company style that would offend any fresh CS major in that they could be shown the style and told that style is not negotiable. This would show if they are a team player or not. A genuinely good programmer would know that after a week of programming the new style that they would be fine with it.
//Comment the crap out of everything. This comment crap also ends up with huge comment headers at the top of every page. The worst comment style is when people break up the parameters to a function onto separate lines; ah la C code from 1982.
But my main complaints about other people's styles is that they do often come from the small assignment to be marked school of needs combined with 50-60 year old professors who learned their stuff in the 80s. This results in rules like: no line longer than 80 characters.
Then there are the document hounds. This comes from the corporate school where managers need yards of documentation. So they insist upon strange comments that proceed every comment with the goal of generating huge documents that nobody will ever read and are probably wrong since they don't generate runtime errors if they get out of sync with the code. This is a case of mission creep where the programmers are also supposed to generate documentation to make the manager able to show he is worth something.
The key is that the style should come from the goal of creating a product quickly, that is bug free, and can be maintained with reasonable ease. Once rules creep in that don't concern these three reasons then they are stupid rules.
I wonder how long you have been writing code, if you don't yet realize that sometimes aligning things vertically across several lines can increase clarity. If everybody gets to set their own indentation amounts (by changing tab width), then this benefit is lost. Tables were invented for a reason, and sometimes code is tabular. And if you think a tab character is how you get a table, you are sadly mistaken.
For example, having same-line comments start at column 60 (when possible) makes code easier to read. If you go changing the tab character to 4 spaces, that alignment is ruined.
Also a reason for not using proportional fonts.
If you think the only way anybody will ever view your code is in a "sane IDE", you are mistaken. Just because your current IDE can compensate for your bad formatting, that doesn't make your bad formatting a good practice.
It's a standard, whether you like it, or know about it, or not.
Whatever style you choose, make sure that it can be generated with whatever automatic formatting tools you have available. This allows you to cut-n-paste code from other sources, and not waste precious time hand-formatting it (or leaving it in the wrong style). It also avoids the problem of lazy programmers feeling butt-hurt when somebody points out that their code does not follow the style. They can simply run their sloppy code through the pretty-printer before committing it.
Only on Slashdot would there be a debate about what constitutes a tab. Half the reason I love this site. Although, why not bring up when it's appropriate to add a space before or after a parenthetical. Using spaces or tabs, you're going to get basically the same result in your code. The real variance is in parentheticals and curly brackets. Those are all over the board.
This signature intentionally left blank.
Sounds like somebody lost his job to a better coder, but doesn't want to admit it.
There is a strong correlation between developers that cannot follow a style standard and divas.
That may be. I am not one of them.
I CAN follow other standards. I already said for example I do so when editing other people's code, right from the outset.
I also CAN follow other coding standards as teh job requires, and have done so a lot.
But what follows from that is experience, and in my decades of experience across multiple languages, coding for both client and server backends coding standards are in fact a total waste of time. That is what I am telling all of you. Yes lots of people can follow a coding standard, but it is wasteful to craft one and to spend the time trying to get coders to follow it.
Especially since there is a lot of grey area: like defining the common vocabulary (like the expected behaviour of getX, createX, findX, selectX, process, run, execute, ...)
What language is most of that gray for? I would also say definitions for how code should behave is actually more API conventions than "coding standards". It is more a design matter.
Free code style, in practice, would only mean that you are working most of the time with code in a different coding style.
Not at all. Read what I said again. Code you are writing from scratch you write how you like. Code from other people you try to keep the given style. So over time you spend only a little time coding in other styles, most of the time in a module that you have been working and and debugging. There might be some small negotiation if one or two other people are in the exact same code as you at the same time to not write something in a way they really dislike, but it doesn't need to be an edict from oh high to work out.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That's what you don't understand - people can look back through history and realize that I consistently advocate a position, not that I'm some loser AC yanking chains like yourself. My posts are serious; AC posts on a topic like this are pretty much meaningless garbage because you can't tell anything about the level of experience the person posting has.
Hell, even my UID alone tells people I have 10000x more believability than yourself.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What you have laid out is way better than the end result of most coding standards, where all of them would have been named "feature_37_count". You know it's true.
Also variants of naming are easily cleaned up later by refactoring tools if the situation gets to be as dire as you have presented. If there's a good reason to help make the code more consistent in that way one should do so; it's not the same as re-formatting a file...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Code editors (at least most of them) are still stuck in a dark age where everything comes down to hand-crafted ASCII-art, which is complete and utter bullshit. Editors could and should work much closer, if not directly on, the AST of the language in question, and completely abstract away all those pesky details like indenting scopes or formatting comment blocks "properly". That stuff should be left to user preference and style sheets.
But I guess that would put an immediate end to the religious zeal displayed in tabs-vs-spaces (it's of course ts=8 sw=4 noexpandtab, noobs!), would not mask syntax errors in gobs of meticulously crafted gunk, and take all the "fun" out of programming.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
For Java project a must. Agree on coding standards and then enforce/check them using Checkstyle.
Style guides force people to be sensible.
The thing is - no, no they do not. I've seen plenty of nearly unreadable code that complied (roughly) with local style guides.
If you've encountered rational looking C++ it's because they knew what the hell they were doing, not because the labored under some all-powerful style guide.
That's the trouble with coding standard guys, they claim coding standards work while all the while it is the people who can code clearly without them are the reason they think it is so.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Had to google it, only to find out that this is the style I already use (except that the Wikipedia displays it with indent levels of 4, while I use indent levels of 2) :-)
The Tao of math: The numbers you can count are not the real numbers.
One of my least fofourite has to be GNU style.
I don't know how the fuck stallman came up with the braindead idea to put the braces halfway between the previous and current indent level, but it drives me crazy.
Probably because of a literal translation of the logical structure of C:
The if statement takes exactly one substatement which you normally indent:
Now the {} form is just a compound statement where you generally indent the statements in between relative to the braces, like this:
Now insert the second into the first, and you immediately get:
Of course a literal translation would also lead to things like
which I guess even Stallman would instead write as
The Tao of math: The numbers you can count are not the real numbers.
All I am hearing from everyone is philosophy and opinion, but in all of it there are kernels of truth. It is exactly like religion, there is no difference. With regards to what I use, the bulk of it centers around reducing the amount of time it takes to read a code block. If you can't read a code block in a couple seconds that you haven't seen for years then you're probably doing something wrong.
Non sequitur: Your facts are uncoordinated.
yes it's better to have a consistent codingstyle, BUT what codingstyle is the bigger problem, as what is great to one person might look awfull to another, good codingstyle is all in the eye of the beholder. for instance, comments, one thinks let the code speak for itself, and others think comment on what you intend the code should do.. another example is lambda expressions, some swear by them and use them everywhere to the extreme, others use them only if it doesn't make the code harder to understand (since lambda expressions are 'just' functions/procedures with no name).. As I said, good codingstyle is all in the eye of the beholder, but a team should have at least one global codingstyle...
For 10 concurrent developers it will set you back about $10,000. BattleMap (now called McCabe IQ) will set you back about $30,000 a seat, and can generate test cases for unit tests which will test every branch path, and correlate them back to line items in your requirements documentation.
Probably overkill, if you are not working on a life support system of some kind, but the tools exist.
I love the Borland color scheme. I run that in my code editor. I wish I could find a good TrueType "VGA" font to make it even better.
I'm one of those people who is obsessed with coding style, but I'm not in love with any one style (well, I have my personal style but it changes over time). The main reason I like a style is to "play well with others".
In my job, we have (relatively) brisk turnover as people are brought into the project and moved out. The team size has gone from 2 to 30 and down to 8. People come and people go, but someone has to maintain the code for 20+ years. Having everything consistent makes it easier to bring people in and to keep things flowing easily.
During code reviews (we have them for every check-in), I consider deviating from the coding standard with justification to be wrong. Yes, it is nit-picky that the formatting is off or there is a missing space after the "if" and before the "(", but the simple fact we're working on a codebase that will be maintained by dozens of people over decades. A little work now significantly reduces the effort to maintain it later.
Now, that isn't to say that some standards drive me nuts. We use "m_" in front of our local variables at my current job. I *hate* it, but it is better than nothing. I'd rather go through the regular change process to get consensus instead of abandoning it because of a personal reason. Likewise, I've submitted patches to Mono previous, though I find their coding standards to be... uncomfortable to work with.
In the end, I only care that a standard is in place, not the specifics of it.
Not in Go programming language.