<story><title>Making Wrong Code Look Wrong</title><url>http://www.joelonsoftware.com/articles/Wrong.html</url></story><parent_chain><item><author>raganwald</author><text>Folks, please do not fall into the simple error of arguing whether Haskell’s typing beats Hungarian notation. This would be bikeshedding. The safe/unsafe strings are given as an example, the larger point he is making is about using coding conventions to highlight potential semantic errors.&lt;p&gt;Every program is going to have some kind of semantic problem that cannot easily be fixed with compile-time analysis. Unsafe strings in web applications are merely one example for one class of programs written in one class of languages. If you grasp what he’s saying about coding conventions, ignore the example.&lt;p&gt;So to his actual point: Do you agree with my contention that there are always going to be some semantically wrong bits of code that cannot be automatically detected by the compiler, or that it is awkward to do so?&lt;p&gt;If so, do you think coding conventions help more than they hinder? In other words, do they increase code safety without imposing too much of a burden on readability?</text></item></parent_chain><comment><author>kragen</author><text>&amp;#62; Do you agree with my contention that there are always going to be some semantically wrong bits of code that cannot be automatically detected by the compiler, or that it is awkward to do so?&lt;p&gt;It seems to me that answering this question is more or less exactly &quot;arguing whether Haskell’s typing beats Hungarian notation,&quot; although of course Haskell type systems aren’t the only possible alternative.  For example, any number of templating systems in languages like Python use late-bound method calls and run-time type checks, instead of static typing, to avoid cross-site scripting errors.&lt;p&gt;The problem, to me, is that Hungarian notation (and other coding conventions) only helps you detect semantic errors in cases where the errors can be detected by shallow, local analysis — exactly the kinds of errors that can be detected automatically by a program, either at compile-time or run-time.&lt;p&gt;So, what do we do about the deeper errors?  Well, I don&apos;t know.  I don&apos;t think abandoning coding conventions is a solution — I still want the code I read to be written in a predictable style, so that the variation in it is semantically meaningful — but I don&apos;t think coding conventions can do a better job than software of detecting errors.&lt;p&gt;However, if I were trying to write a GUI on a 1-MIPS machine with 1 MiB of RAM in the late 1980s, it might work better to do a bunch of that checking by hand (with Hungarian) than to try to invent a better programming language that does the checking for me automatically.</text></comment>
<story><title>Making Wrong Code Look Wrong</title><url>http://www.joelonsoftware.com/articles/Wrong.html</url></story><parent_chain><item><author>raganwald</author><text>Folks, please do not fall into the simple error of arguing whether Haskell’s typing beats Hungarian notation. This would be bikeshedding. The safe/unsafe strings are given as an example, the larger point he is making is about using coding conventions to highlight potential semantic errors.&lt;p&gt;Every program is going to have some kind of semantic problem that cannot easily be fixed with compile-time analysis. Unsafe strings in web applications are merely one example for one class of programs written in one class of languages. If you grasp what he’s saying about coding conventions, ignore the example.&lt;p&gt;So to his actual point: Do you agree with my contention that there are always going to be some semantically wrong bits of code that cannot be automatically detected by the compiler, or that it is awkward to do so?&lt;p&gt;If so, do you think coding conventions help more than they hinder? In other words, do they increase code safety without imposing too much of a burden on readability?</text></item></parent_chain><comment><author>perlgeek</author><text>&amp;#62; Every program is going to have some kind of semantic problem that cannot easily be fixed with compile-time analysis. Unsafe strings in web applications are merely one example for one class of programs written in one class of languages. If you grasp what he’s saying about coding conventions, ignore the example.&lt;p&gt;I disagree. If the example has a better solution (and in some other comment here I argue it does, though it&apos;s not at compile time), it&apos;s well worth looking if that solution could be transferred to other problem domains that could be used as examples instead.&lt;p&gt;The deeper issue is that naming conventions are a kind of automatism, and humans shouldn&apos;t be bothered with that, they are simply not very good with this type of automatism. For repetitive patterns, automated solutions should be used.&lt;p&gt;Advocating these repetitive type prefixes reminds me of the classical Design Patterns -- they might be the best option if you&apos;re stuck with one set of tools, but IMHO it&apos;s important to take a broader view and see if there are maybe other tools that can alleviate the need of such patterns. And indeed, in the case of the classical Design Patterns, there are. More powerful languages render some of them obsolete, or turn them into trivial 3 line solutions that you can hardly call &quot;patterns&quot; anymore.</text></comment>