Ruining the diversity of JavaScript community with a coding style guide(github.com)
github.com
Ruining the diversity of JavaScript community with a coding style guide
https://github.com/airbnb/javascript/issues/102
30 comments
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.
Issue author here.
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'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
Everyone formats their code wrong except for me.
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.
My only fear is that people will abuse
a single style guide to no end and code
will become generic and timeless.
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.
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.
That's just, like, your opinion, maaaaan.
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.
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.
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.
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.
Yeah, for code, "timeless" is definitely something you want to strive for.
Timeless code is code that you can look back on years later without saying "WTF was I thinking???"
Timeless code is code that you can look back on years later without saying "WTF was I thinking???"
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".
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".
Code is not only written and executed, it is also read and modified. Bad, broken or inconsistent style can harm readability, and thus maintainability, which detracts from the value of a codebase. It's often easy to fix compared to bad design or architecture, but it does have a cost.
Yes definitely, you're right. What I mean is that bad design or bad architecture can take months to fix while most editors can fix formatting automatically with a few clicks. At the same time I prefer my own projects to have very clear and consistent 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...
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...
Do we agree then over the absolute measure of "elegance"?
[deleted]
Sigh. Not about the original article, but about the top comment in the original article.
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.
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.
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:
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.
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.
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.
[1]http://galleristny.com/2012/10/from-brush-and-palette-to-pri...
"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...
I won't argue that constraints can lead to innovation. All art exists in some medium. Constraints are therefore inherit.
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"?
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"?
Wow, he's such a unique snowflake.
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.
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.
[deleted]
Yes, a style guide "ruins" diversity. That's the whole point.
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.
Picasso said "Inspiration exists, but it has to find you working."
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 (...).
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.
The point of style guides are to leverage best practices and ensure anyone can easily read, understand and modify your code.
"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."