It's not. The bug reporter are the worst type of developers.
They naively think that IT is a creative, artistic endeavour instead of understanding that it far more akin to building a bridge or building. It's by and large a team effort where you all have to be able to jump in and support each other's work at any time.
Trying to see it from their perspective, I can think of a few edge cases where the commenter might have a valid concern.
For example, imagine a rigidly enforced style guide a from several years back that talked about the default return value for functions when there is no return value (e.g. always use void or something like that). Such a style guide, if rigidly enforced, might preclude the now-common idiom of method chaining, which has some really nice/useful applications.
That said, consistency in code is a good thing. Think of it as another form of convention over configuration. Just don't be so rigid with it as to lock out interesting ideas/experiments every now and then.
Code style shouldn't change the value of code in any way. If it does something went horribly wrong :)
For me code's value comes from what the code does and how elegant the overall implementation is. Code's value definitely doesn't come from formatting or "style".
"Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. Either there is more to habitability than clarity or the two characteristics are different. Let me talk a little bit more about habitability before I tackle what the difference may be.
"Habitability makes a place livable, like home. And this is what we want in software - that developers feel at home, can place their hands on any item without having to think deeply about where it is. It’s something like clarity, but clarity is too hard to come by."
I facepalmed at "Imagine if when Picasso was learning to paint, we told him what style he should paint in. Would we have cubism?". The answer is not only yes, but yes, and that is exactly what happened.
This is the style Picasso was told to paint in when he was learning to paint:
I would actually take the "blue period" example as Picaso's own styleguide. By forcing constraints on himself (like a much reduce palette), he got much more creativity out.
"When Picasso purged color from his work, he did so to emphasize the formal autonomy of the picture plane and focus on problems of form." [1]
Styleguides don't hinder creativity. They help it shine. It simply a set of constraints that help guide you through the creative process. Same as convention-over-configuration. Yes, you are forced to put certain files in a certain folders, but that just saves you time, it does nothing to stop you from being creative.
I am not sure if I want to be harsh and ask why would anyone object to a coding style. If you were coding for your own project, do you not have a specific preference on how the code is written? I think I do.
A code base is a living document, and it changes as it grows and responds to new requirements, or is patched or refactored to fix old bugs. The git log is a history of everything that happened to that code base over its lifetime to date. If that log is full of people committing small style changes because they don't agree with the last guy's position on semi-colons or the use of array literals or how many characters to indent by, then I'd argue that it's actually a less meaningful work. If you're looking for beauty, elegance and meaning in the code, you'll find it in the clear expression of intent that you get when the changes are about function rather than form. Where's the beauty in a "Fixed indenting" commit? What does it tell you other than that someone ran their editor's auto-indenting routine?
Adherence to a common style keeps such noise to a minimum, leaving you with a commit history that's full of meaningful changes rather than meaningless thrashing over whether to indent four characters or two, or whether the { goes on the same line as the if (...).
Coding styles can often be enforced through automated means before checkin. And even if they can't it is trivial to flatten commits to make style changes disappear.
The point of style guides are to leverage best practices and ensure anyone can easily read, understand and modify your code.
By contrast, if every language had a correct style and came with a formatting tool for automated enforcement, it would free developers to focus exclusively on things that matter.
Picasso actually knew how to paint "properly" before inventing cubism. We have a weird misconception of "Genius" in our culture, where we think that "Genius" are somehow born with natural talent and skill, while in fact, a lot of them just had a lot of training which enabled them to be Geniuses.
I don't think that using single quotes will ruin the diversity. This code style guide is all about some minor stuff, which is rather meaningless. After all this kind of things does not instant make code base good or bad.
On the other hand, a good style guide should also include best practices (this one seems to do that for a number of items) which might not instantly make the code good, but can at least have a positive impact.
I always prefer double quotes for strings in JS though. At least for variables, not selectors; seems much more common to have a single quote within a string than a double.
[+] [-] aaronbrethorst|12 years ago|reply
[+] [-] threeseed|12 years ago|reply
They naively think that IT is a creative, artistic endeavour instead of understanding that it far more akin to building a bridge or building. It's by and large a team effort where you all have to be able to jump in and support each other's work at any time.
[+] [-] zacharypinter|12 years ago|reply
For example, imagine a rigidly enforced style guide a from several years back that talked about the default return value for functions when there is no return value (e.g. always use void or something like that). Such a style guide, if rigidly enforced, might preclude the now-common idiom of method chaining, which has some really nice/useful applications.
That said, consistency in code is a good thing. Think of it as another form of convention over configuration. Just don't be so rigid with it as to lock out interesting ideas/experiments every now and then.
[+] [-] kalleboo|12 years ago|reply
Timeless code is code that you can look back on years later without saying "WTF was I thinking???"
[+] [-] mikko-apo|12 years ago|reply
For me code's value comes from what the code does and how elegant the overall implementation is. Code's value definitely doesn't come from formatting or "style".
[+] [-] stevecooperorg|12 years ago|reply
"Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. Either there is more to habitability than clarity or the two characteristics are different. Let me talk a little bit more about habitability before I tackle what the difference may be.
"Habitability makes a place livable, like home. And this is what we want in software - that developers feel at home, can place their hands on any item without having to think deeply about where it is. It’s something like clarity, but clarity is too hard to come by."
[+] [-] scottdw2|12 years ago|reply
It presumes that Picaso, Bansky, and Monet can't paint like each other.
Probably not true if you actually have Picaso, Bansky and Monet.
In any case, style guides are for hacks, not artists.
[+] [-] twic|12 years ago|reply
This is the style Picasso was told to paint in when he was learning to paint:
http://mesosyn.com/pp-early.html
It was only after he had mastered this conventional style of painting that he went on to discover cubism.
[+] [-] gingerlime|12 years ago|reply
"When Picasso purged color from his work, he did so to emphasize the formal autonomy of the picture plane and focus on problems of form." [1]
Styleguides don't hinder creativity. They help it shine. It simply a set of constraints that help guide you through the creative process. Same as convention-over-configuration. Yes, you are forced to put certain files in a certain folders, but that just saves you time, it does nothing to stop you from being creative.
[1]http://galleristny.com/2012/10/from-brush-and-palette-to-pri...
[+] [-] yeukhon|12 years ago|reply
[+] [-] rjknight|12 years ago|reply
Adherence to a common style keeps such noise to a minimum, leaving you with a commit history that's full of meaningful changes rather than meaningless thrashing over whether to indent four characters or two, or whether the { goes on the same line as the if (...).
[+] [-] threeseed|12 years ago|reply
The point of style guides are to leverage best practices and ensure anyone can easily read, understand and modify your code.
[+] [-] adamnemecek|12 years ago|reply
[+] [-] ahoge|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] mratzloff|12 years ago|reply
[+] [-] JacksonGariety|12 years ago|reply
I've thought about this quite a bit today and decided style-guides are a necessity, and permissible as long as they are living documents.
GitHub's open-source philosophy makes this easy, so I've forked airbnb/javascript to my own variation and strongly encourage others to do the same.
JacksonGariety/javascript: https://github.com/jacksonGariety/javascript
[+] [-] wirrbel|12 years ago|reply
[+] [-] Jare|12 years ago|reply
[+] [-] ghostdiver|12 years ago|reply
[+] [-] james-skemp|12 years ago|reply
I always prefer double quotes for strings in JS though. At least for variables, not selectors; seems much more common to have a single quote within a string than a double.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] iterative|12 years ago|reply
[+] [-] lizard_boy|12 years ago|reply
[deleted]
[+] [-] rtcom|12 years ago|reply
[deleted]