[codecraft] Douglas Crockford: Perfection, not beauty, must be our goal.

[Philip Durbin]

https://plus.google.com/+DouglasCrockfordEsq/posts/38gFCvtTUTP

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.

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.

But reasoning about programming style is surprisingly difficult. For
example, someone recently wrote this in the G+ JSLint community:

    I have definitely found cases were using assignment
    expressions create beautifully compact code that I
    think is much easier to read than the alternative.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://or8.net/pipermail/codecraft/attachments/20160129/4f8f3253/attachment.html>