
Ruining the diversity of JavaScript community with a coding style guide - zdne
https://github.com/airbnb/javascript/issues/102
======
aaronbrethorst

        My only fear is that people will abuse
        a single style guide to no end and code
        will become generic and timeless.
    

Wait, what? This is a _bad_ thing?

~~~
mikko-apo
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".

~~~
Jare
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.

~~~
mikko-apo
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...](https://github.com/JacksonGariety/javascript/commit/e06e9a46b102a3cf83216ff9eb6bcaf76de09c72)

------
stevecooperorg
Reminds me of Richard P Gabriel's essay on _Habitability_ (PDF, Page 9,
[http://dreamsongs.net/Files/PatternsOfSoftware.pdf](http://dreamsongs.net/Files/PatternsOfSoftware.pdf))

"Habitability is the characteristic of source code that enables programmers,
coders, bug-ﬁxers, and people coming to the code later in its life to
understand its construction and intentions and to change it comfortably and
conﬁdently. Either there is more to habitability than clarity or the two
characteristics are diﬀerent. 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
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.

~~~
gingerlime
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...](http://galleristny.com/2012/10/from-brush-and-palette-to-printer-and-
cartridge-picasso-black-and-white-at-the-guggenheim-wade-guyton-os-at-the-
whitney/)

~~~
scottdw2
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"?

------
yeukhon
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.

------
rjknight
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 (...).

~~~
threeseed
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.

------
adamnemecek
Wow, he's such a unique snowflake.

------
ahoge
Yes, a style guide "ruins" diversity. That's the whole point.

------
mratzloff
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.

------
JacksonGariety
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](https://github.com/jacksonGariety/javascript)

------
wirrbel
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.

~~~
Jare
Picasso said "Inspiration exists, but it has to find you working."

------
ghostdiver
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.

~~~
james-skemp
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.

------
iterative
Everyone formats their code wrong except for me.

