Ruining the diversity of JavaScript community with a coding style guide
github.com
github.com
My only fear is that people will abuse
a single style guide to no end and code
will become generic and timeless.
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.
Granted there's a pretty broad spectrum of kinds of projects and kinds of collaboration. But even in the broadest most open of collaborations, fundamentally there are aesthetic, stylistic and design decisions being made about API structure and the usability of a code base's constructs (which is what is so frustrating about watching new communities of new programmers coalesce w/o the benefit of hindsight from previous cultures/systems).
It's just a hop, skip and a jump from those higher level domain concerns down to actual coding style.
Also, buildings and bridges are creative and artistic endeavors.
Edit: To be a little less flippant about it, the broader point is that writing code is always a stylistic endeavor. You can agree with your colleagues or friends explicitly on style conventions, or you can roll with organically created conventions. But to say that you can write code devoid of design decisions and stylistic choices is foolish (again, all buildings and bridges are designed objects, and sure there are best practices for how concrete is poured, but to declare that construction has no craftsmanship is incorrect).
Beyond that, the utility of forcing others to adhere to your style is one that should be more rigorously considered. My vast preference is to ensure that large engineering structures are constructed of compact and well factored components with sane/intuitive APIs, regardless of what their internal stylistic choices are w/r/t formatting.
Having a global style guide across multiple projects might be nice, but it also might be stymieing in terms of iterating towards better practices.
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.
Timeless code is code that you can look back on years later without saying "WTF was I thinking???"
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".
I think the original poster (and the topic here) is using way too strong words for such an irrelevant issue. It's airbnb's project, they get have their own opinion. Their style guide won't ruin the Javascript community.
Also, the original poster seems to be on a mission of his own. He forked the project @ github, did a few modifications and changed the documentation in a way that conflicts with the original MIT license. Poisonous attacks like that are what destroy communities.
https://github.com/JacksonGariety/javascript/commit/e06e9a46...
"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."
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.
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.
"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...
Here's a simple question: what spurred Picaso's decision to paint in Blue? Was it adherence to a protocol describing blue as the answer to his expressive woes, or was it his own internal experimentation with the color blue?
Did Picaso paint in blue because he felt like Blue, or because someone said "any work 'submitted' to this gallery must be blue"?
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 (...).
The point of style guides are to leverage best practices and ensure anyone can easily read, understand and modify your code.
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
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.