
Best Practices Exist For A Reason - jashkenas
http://tomdale.net/2012/04/best-practices-exist-for-a-reason/
======
jashkenas
The main problem with appealing to "best practices" is this: One man's best
practice is another man's anti-pattern.

Between semicolon-free folks and JavaScript traditionalists, who gets to play
the role of the expert? If Node.js is popular, does that mean that Isaac's
comma-first style is "correct"? (<https://gist.github.com/357981>)

In the absence of a quantitative engineering method with which to evaluate
either approach, isn't it a purely personal and political choice?

~~~
keyist
"Between semicolon-free folks and JavaScript traditionalists, who gets to play
the role of the expert?"

You're framing this as a disagreement between equals. It is not. There are
degrees of expertise. (Total lines of production code * amount of usage) is a
reasonable approximation, and those who rank highest on this scale are
overwhelmingly in favor of requiring semicolons.

If Carmack and Torvalds were in agreement on a C best practice while
Odesker^W^W^W^W^W^W^W Topcoder user #12571 said to do something else, I
wouldn't go with the latter.

Google, responsible for a JS engine, multiple compilers that target JS, and
what is likely to be the single largest JS codebase of any company:
[http://google-
styleguide.googlecode.com/svn/trunk/javascript...](http://google-
styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Semicolons)

Brendan Eich: "The moral of this story: ASI is (formally speaking) a syntactic
error correction procedure."

Or you can go with the Node.js guys.

~~~
Darmani
You can think about the effect of coding style instead of letting the experts
think for you.

If you are doing a Topcoder round, then the random Topcoder user's advice is
probably better than Carmack's. Carmack or Torvalds would probably tell you to
use a variable name that gives a lot of information about its purpose, so that
other people will find it easier to read your code. The Topcoder user might
tell you to use a cryptic abbreviation that helps you remember a variable's
purpose but clues little to the outside reader, since Topcoder users are
penalized for allowing others to find their bugs. When implementing an
algorithm, Carmack or Torvalds would code it as part of an extensible system
with an API so that it can be used for many purposes. The Topcoder user might
code it with no potential for reuse, but would do it in the way easiest to
code quickly without making a mistake.

~~~
freshhawk
"You can think about the effect of coding style instead of letting the experts
think for you."

Right, because what could those experts possibly have to teach you? Fuck that
intellectual crap, brogrammers are here to crank out some code yo! Just
because those dinosaurs have spent "thousands of hours" studying and trying
out different programming styles and concepts means I should listen to them?
This is the internet age man. Some guy in a github comment told me different
and github is cool.

It's like those functional programming professors who try and talk about how
continuation passing style was a bad road to go down because of maintenance
problems and how difficult refactoring and just reasoning about code becomes
in large systems.

Fuck that egghead noise, node.js has callbacks and node is how you get
webscale.

I'm right with you bro!

~~~
slowpoke
You completely and utterly missed the point, in addition to just being
needlessly rude.

The point of your parent was "don't let the experts think for you", not "screw
the experts" - that's a very important distinction. You should form your own
opinions, not just uncritically adopt the opinion of some expert. It's
unquestionable that expert knowledge and experience is important - but nothing
beats forming your own (hopefully informed) opinion.

~~~
freshhawk
Who said "let the experts think for you"? No one. You were arguing against
"give the experts' opinions more weight than others, often a lot more"

"You should form your own opinions, not just uncritically adopt the opinion of
some expert."

False dichotomy again, there is a lot of ground between "uncritically adopt
the opinion of some expert" and "forming your own opinion and hoping it's
informed".

You should find that middle ground, it's where all the smart people are.

I didn't miss the point at all, I just completely disagree with you. I don't
think it was needlessly rude either, it was sarcastic. And I feel no need to
treat people who are promoting anti-intellectualism with kid gloves.

~~~
Darmani
Intellectualism is not about showing off how much you agree with authorities.
Intellectualism is about thinking and understanding, eventually until you
become one.

When discussing coding style, you can quote experts. Or you can understand
their arguments, understand the impact and tradeoffs of coding decisions, and
realize why they are true. And in the case of Topcoder, about as far as
possible from building large systems, you can realize that the optimum style
changes and understand why.

I think there's a broad trend to treat code as magic, something where anything
can happen. Most people learn coding styles by being given suggestions, and
then noticing from experience that they like it better. If you reject this
mindset and believe that code is orderly, then this advice changes from Wisdom
of the Elders (TM) into an engineering calculation. I specialize in automated
restructuring of software architecture, so this mindset is something I try
hard to fight against.

~~~
freshhawk
I don't see how this applies to me taking issue with the parents "figure it
out yourself instead of letting the experts think for you" statement.

"Intellectualism is not about showing off how much you agree with authorities"

My point was that intellectualism is not about agreeing with authorities but
giving proper weight to the opinions of intellectuals in the field when
weighed against lay opinions or smaller groups of intellectuals.

You certainly don't seem to be arguing for the post-modern interpretation I
was arguing against where expert opinion is considered "just another opinion,
equally valid" so I'm confused why you think my stance is almost the opposite
of what I was stating.

~~~
Darmani
The opinion of an intellectual is indeed stronger Bayesian evidence than that
of a layperson. But if they have an opinion, they should provide an argument
to back it up, and that argument is far more important.

My first comment hit the advice to always follow Carmack over the random
Topcoder user. It's important to understand what makes a best practice a best
practice rather than just listening. A Topcoder round and Quake differ greatly
enough that the random Topcoder user is sometimes the greater authority.

You seemed to map the call to critically evaluate expert opinion to a call to
ignore it, something I'm sure you've seen too much of. But it's important to
understand the difference between critical evaluation and anti-
intellectualism. Indeed, the former is the higher form of respect.

~~~
freshhawk
In general I agree completely, standard philosophy of science stuff.

I'm not sure how well it applies to a subject like best practices where it's
either subjective or at least fuzzy. The arguments are "in my experience this
causes problems when working with other people and is more prone to errors
long term". There have been no counter examples or analysis I've seen around
this issue, just a "that's just what the traditionalists say" type argument.
Something along the lines of your topcoder example that applied to the
semicolon argument (god i hate this issue) would be very welcome.

Any critical analysis here is hard to do objectively, and there is a consensus
of experts (including Eich) on one side. If i'd seen any actual critical
analysis rather than a jump to "don't let the experts tell you what to do! be
a rockstar!" then I wouldn't been so fast to use the anti-intellectualism
card. But it's so prevalent in the node community (more than Ruby's but less
than PHP's) that it's depressing.

~~~
Darmani
The reason for using semicolons in JS is quite simple: It makes it easy to
determine the boundaries between statements, both for humans and machines.

With semicolons, the search for the boundary between statements reduces to the
search for that single character -- that means fast code skimming.

The boundary is also robust against changes; as long as that semicolon stays
in place, nothing that happens within that statement can cause that boundary
to become an interior.

There is an exception: Strings. This is no trouble for machines, as strings
are processed by the lexer. Humans can't instantly take a string and process
it as a chunk, but a UI innovation does this work for us: syntax highlighting.

As an example, consider the code:

    
    
      x = a && b
      foo()
    

If I try to change the "b", I might accidentally turn the code into

    
    
      x=a &&
      foo()
    

The grammar allows the malformed statement to interact with its neighbor, and
thus, instead of getting a parser error, I'll get a program bug.

LR parsers take advantage of this for error recovery, allowing them to find
more than one parse error at a time.

A more sophisticated view is to think about syntax abstractions. Given a
program like "x=y; return x;" we can create a program written in the abstract
syntax "statement; statement". (The dual operation is to concretized that back
into the set of all two-statement programs. This kind of relationship is known
a Galois connection.) Having semicolons makes the abstract syntax unambiguous,
allowing us to efficiently reason at the statement level.

~~~
freshhawk
We're so off track that it's been lost that all my points are very definitely
pro-semicolon?

~~~
Darmani
You asked for an analysis of why semicolons are good, and you got it.

------
bitops
JavaScript and semicolon controversy aside - I'm always happy when I read a
post written in this style. It's clear (at least to me) that the author has
taken the time to think about what they're saying, and they present clear
arguments. I always hope that more people write this way; in the style of what
I feel is real discussion.

------
benatkin
First, Isaac Schlueter isn't advocating against best practices with ASI. He's
advocating for an alternate best practice that you disagree with. In that very
article he suggests an alternate place to put the necessary semicolons.

Second, the CouchDB thing isn't because of a lack of best practices, it's
because the wrong best practices were misapplied. And in the end, its use of
best practices prevented it from severely hurting CouchDB's reputation.

The best practice is that password data should be stored as a salted hash, so
if the database is compromised, the original password can't be retrieved. It's
rare that the salted hash is intended to be public information, and that's
what the CouchDB people did. What they should have done is realized that since
they're deliberately sharing the hashed passwords, the original best practice
doesn't apply, and they need to break it down and reexamine it (probably a
good idea anyway for a project of its size). And they should have reached the
conclusion that SHA1 is much too weak and/or that the salted passwords
shouldn't be shared. In the new version, CouchDB 1.2, where an effort to
correct the problem was made, the passwords aren't public. But at least, aside
from the encryption strength, they got the hashing right, in that they used
salts so rainbow tables can't be used. SHA-1 is easy to brute force for simple
passwords, but as passwords get longer and contain more than dictionary words,
it gets harder to brute force. It's easy to communicate that they screwed up,
and easy to communicate that it's no worse than Sony password databases that
were compromised, but the truth lies somewhere between the two, and can be
seen by carefully considering the details of the case.

~~~
ehutch79
you can't have alternative best practices... the BEST in best practices kind
of makes that clear.

best practices and most practical practices are not always the same though.

------
bertzzie
Also relevant: Most best practices exist without explanation. We are supposed
to just use it without question. I think that's what Issac meant with "fears
and lies" (not that I agree with his statement). Raymond Chen puts it great:

 _Good advice comes with a rationale so you can tell when it becomes bad
advice. If you don't understanding why something should be done, then you've
fallen into the trap of cargo cult programming, and you'll keep doing it even
when it's no longer necessary or even becomes deleterious._

source:
[http://blogs.msdn.com/b/oldnewthing/archive/2009/11/04/99170...](http://blogs.msdn.com/b/oldnewthing/archive/2009/11/04/9917052.aspx)

------
madhadron
The real question is why anyone takes obviously wrong artifacts in JavaScript
like omitting semicolons and flagrantly wrongly designed this binding
seriously. This isn't an issue of best practices or personal preferences, it's
aspects of a ubiquitous language that are simply and unequivocally broken.

~~~
tikhonj
This just begs the question: they're broken, because they're broken? And
anybody who thinks the features neat is wrong?

The reason people talk about omitting semi-colons in JavaScript is because
they _don't_ think that feature is unusable--they clearly think it's better
than adding semi-colons everywhere! When reasonable people disagree like that,
the situation is rarely simple and clear-cut.

Now, perhaps you could reasonably argue that the behavior is unfortunate. But
you can also reasonably argue the converse. And, most importantly, it isn't
immediately clear who is correct.

~~~
JamisonM
It has always been a mystery to me that reasonable people somehow think it is
better to omit the semicolons where you can instead of just being 100%
consistent by using them to terminate every statement. I have always thought
that computers, programming, logic were always all about favouring consistency
and simplicity. My mind boggles that otherwise talented people do not see the
value in using simpler rules when they work and avoiding exploiting complex
things that seem to offer somewhere between little and no extra value.

I guess I just don't get it because it has always seemed precisely a simple
and clear-cut thing to me but somehow it is not.

------
jtchang
This is my love/hate relationship with JavaScript. There is often more than
one "correct" way to do things and there is a lot of disagreement in the JS
community about what way is "best".

Contrast this with Python where the overarching rule is there should be one,
and preferably only one, obvious way to do things.

~~~
artsrc
These kind of support your position:

<http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces>

The most popular way of indenting Python is with spaces only. The second-most
popular way is with tabs only. For new projects, spaces-only are strongly
recommended over tabs.

Function names:

...

mixedCase is allowed only in contexts where that's already the prevailing
style (e.g. threading.py), to retain backwards compatibility.

------
nherment
Very well written post.

However, I found it to be of little value. When fully reading Isaac's post
([http://blog.izs.me/post/2353458699/an-open-letter-to-
javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-
leaders-regarding)), it appears to not diverge much from what you've written.

I consider myself a beginner in Javascript and did not find Isaac's post the
least condescending. I actually learned a few things and am very glad he took
the time to explain how things work. Because honestly, I won't read the
ECMAScript spec unless I need to.

I'm actually one of the people who never use semi-colons to terminate
statements. That's for personal projects. Where I work, we (as a team) decided
to use them. And that's fine, but I prefer not to use them.

------
hef19898
If I could I would up-vote this post twice at least! And it is not the Java,
node.js, where-do-you-put-your-semicolon part of it. I don't undersand any of
it. No, it is more the view on best practices. And there, I completely agree.

I'm part of HN not for very long, but what strikes me are the similarities
between supply chain management and programming in some aspects. The purely
technical issues are out of scope here since I cannot judge them, it's more
about the principles behind. Like in this case here.

Best pratices provide a guideline and are condensed experience. They are by no
means the only or best solutions, rather ones that can be applied in a lot of
cases withou screwing up. That said, one should also reach a point where
understand them. One has to in order to understand when to use them, most
people get at least to that point.

What you actually have to do is reach an understanding of not only when to use
best practices but one of knowing why you use them. This is not true mastery,
but it will get you far enough.

Ultimately, you need people who know when to use a best pratice, when to
ignore them and when to actually brek conventional wisdom. What I see a lot
lately is people doing the last to bits without having understood the best
pratice's when and why in the first place.

For me, that's the key message of this post, and this point is valid in every
industry, sector or task at hand.

------
fizx
With respect to style and syntax at least, this is why I like golang. There is
one true way to format a go program, and there is a compiler/autoformatter to
enforce it.

------
mistercow
>By couching it in these terms, it implies that anyone who follows best
practices has given in to “lies and fear!” Who wants to be swayed by that?

That is some fairly brazen rhetorical sleight of hand. Schlueter is obviously
not attacking the following of best practices. He is saying that semicolons-
everywhere _isn't a best practice_ and he gives an argument that the most
common rationales given for the practice do not hold water. There are a few
flaws with his argument, but what it certainly is not is a general
condemnation of the following of actual, bonafide best practices.

Pretending otherwise is akin to accusing someone of "siding with the
terrorists" because they argue that people should be allowed to take bottled
water on airplanes.

------
ZenPsycho
Having too many semicolons will never ever cause you a problem. Having too few
almost certainly will. Why is this an argument? Don't we have enough bugs to
deal with? just use the semicolons, or get out of my way.

Most arguments about style are almost certainly pointless, but if you are
faced with a choice between two styles, one of which may cause a problem
sometimes if you don't know what you are doing, and the other style, which
will never ever cause you a problem, it seems the choice is kind of obvious,
no? Particularly since the guy doesn't really make a case for what his
objection to semicolons actually is to begin with. He doesn't like the look of
them?

------
jimmyjazz14
Many best practices work well because they mean you don't ever have to think
about uninteresting problems (like ASI) ever again. I know the rules of ASI
but I honestly have never had to think about them because, I don't need to; I
just put a semicolon at the end of my lines.

If you ever have to do network and systems administrations you will come
across loads of best practices because needing to memorize every last rule and
edge case of all the software on your systems would be truly maddening.

That said, it is always good to know the why behind best practices and not
follow them blindly.

------
Isofarro
;

Best practice is about a practice that helps create maintainable code. Code is
maintained by people. So a best practice is really about getting the best code
delivered by the people you have in the most appropriate time possible, and
code that can be maintained by those same group of people and others who may
be brought into the project at a later date.

Insisting on semicolons means that the bar to entry for being able to develop
and maintain a JavaScript code base is lower. Also, we can spend more time
thinking about the purpose of the code rather than it's syntax. That helps
when it comes to debugging, spending more time thinking about what the code is
trying to do rather than losing time figuring out whether the syntax without
semicolons is causing an unintended side effect.

The lack of semicolons argument reminds me of the Python versus Java argument.
Choosing python gives you a much smaller range of people who could work on
your project, but on average the quality of that developer would be better
than if you opted for Java.

The advantage of the non-semicolon stance is that they are increasing the
minimum level of competancy before someone can work on their project. The
disadvantage of the non-semicolon stance is that they are increasing the
minimum level of competancy before someone can work on their project.

------
DannoHung
God I hate JavaScript. It's the C++ of the new millenium. 10 gallons of shit
in a 5 gallon hat. Dominant only because of switching costs.

Fuck Javascript. Good parts be damned.

~~~
lowboy
Good for you, stay away from it. One less half-assed js developer in the
world.

------
Produce
Best practices are invaluable when used as a guideline. They are abhorrent
when used as a rule.

------
evanlong
And that is why... you use node.js. checkout out @whyyouusenodejs on twitter.

------
madrobby
Good to know that depending on the author of an article, some stories don't
get flagged and disappear from the front page of hacker news.

