<p dir="ltr"><a href="https://plus.google.com/+DouglasCrockfordEsq/posts/38gFCvtTUTP">https://plus.google.com/+DouglasCrockfordEsq/posts/38gFCvtTUTP</a></p>
<p dir="ltr">FORTRAN was not the first language to make the mistake of using the equal sign to mean assignment, but it was popular and influential. There were later languages that did not repeat that mistake, including ALGOL and BCPL. Unfortunately, C followed FORTRAN's example, compounding the mistake by making == the equality operator. JavaScript compounds C's mistake by making == unreliable. The fix, adding a === operator, does not seem much like a fix.</p>
<p dir="ltr">There is a very good argument that programming languages should not have any sort of assignment operator at all, but the mainstream of our profession is still not ready to hear that argument. But if there is an assignment operator, common sense should demand that it not be confused with the equality operator. Sadly, common sense rarely prevails in the design popular programming languages. That is why JSLint prohibits use of assignment in expression position, comparison in statement position, and == in any position. Those prohibitions allow you to easily avoid a class of nasty bugs. JSLint's prohibitions do not prevent the crafting of good programs. They actually make it easier.</p>
<p dir="ltr">But reasoning about programming style is surprisingly difficult. For example, someone recently wrote this in the G+ JSLint community:</p>
<p dir="ltr">    I have definitely found cases were using assignment<br>
    expressions create beautifully compact code that I<br>
    think is much easier to read than the alternative.</p>
<p dir="ltr">The appeal to beauty gives this the appearance of a powerful argument. But beauty is at best subjective. Certainly in the arena of computer programs, there is not a standard of beauty, so that leads to the conclusion that all representations are acceptable because everything must be attractive to somebody.</p>
<p dir="ltr">But programs have a requirement that they be completely free of error. This requirement is imposed by the computers, because they give themselves license to do terrible things when our programs are not perfect. Perfection, not beauty, must be our goal. I too used to make emotional arguments about programming, and I too had no awareness of how vacant my arguments were.</p>
<p dir="ltr">JSLint has been my mentor on programming style. I did not write JSLint to force my sense of beauty on others. I wrote it to find defects in programs, specifically in my programs. JSLint taught me that if I care about the correctness of my programs, and that should always be our first concern, then I needed to correct my idea of what a good program looks like. We should seek to increase the visual distance between a good program and a bad one. We should not be creating beautiful pockets in which bugs can hide when there are better alternatives.</p>