My only fear is that people will abuse
a single style guide to no end and code
will become generic and timeless.
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...