![\"This](\"https:\/\/i0.wp.com\/www.joelonsoftware.com\/wp-content\/uploads\/2005\/05\/DoughRounder.png?w=730&ssl=1\")
The whole concept of clean in the bakery was something you had to learn. To an outsider, it was impossible to walk in and judge whether the place was clean or not. An outsider would never think of looking at the inside surfaces of the dough rounder (a machine that rolls square blocks of dough into balls, shown in the picture at right) to see if they had been scraped clean. An outsider would obsess over the fact that the old oven had discolored panels, because those panels were huge<\/em>. But a baker couldn\u2019t care less whether the paint on the outside of their oven was starting to turn a little yellow. The bread still tasted just as good.<\/p>\nAfter two months in the bakery, you learned how to \u201csee\u201d clean.<\/p>\n
Code is the same way.<\/p>\n
When you start out as a beginning programmer or you try to read code in a new language it all looks equally inscrutable. Until you understand the programming language itself you can\u2019t even see obvious syntactic errors.<\/p>\n
During the first phase of learning, you start to recognize the things that we usually refer to as \u201ccoding style.\u201d So you start to notice code that doesn\u2019t conform to indentation standards and Oddly-Capitalized variables.<\/p>\n
It\u2019s at this point you typically say, \u201cBlistering Barnacles, we\u2019ve got<\/em> to get some consistent coding conventions around here!\u201d and you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money, and you decide that it\u2019s not really a bad thing to only reformat code when you revisit it, so you have about half of a True Brace Style and pretty soon you forget all about that and then you can start obsessing about something else irrelevant to making money like replacing one kind of string class with another kind of string class.<\/p>\n As you get more proficient at writing code in a particular environment, you start to learn to see other things. Things that may be perfectly legal and perfectly OK according to the coding convention, but which make you worry.<\/p>\n For example, in C:<\/p>\n char* dest, src;<\/strong><\/tt><\/p>\n<\/blockquote>\n This is legal code; it may conform to your coding convention, and it may even be what was intended, but when you\u2019ve had enough experience writing C code, you\u2019ll notice that this declares dest<\/strong><\/tt> as a char<\/strong><\/tt> pointer<\/i> while declaring src<\/strong><\/tt> as merely a char<\/strong><\/tt>, and even if this might<\/em> be what you wanted, it probably isn\u2019t. That code smells a little bit dirty. <\/p>\n Even more subtle:<\/p>\n if (i != 0) In this case the code is 100% correct; it conforms to most coding conventions and there\u2019s nothing wrong with it, but the fact that the single-statement body of the if<\/tt>statement is not enclosed in braces may be bugging you, because you might be thinking in the back of your head, gosh, somebody might insert another line of code there<\/p>\n if (i != 0) \u2026 and forget to add the braces, and thus accidentally make foo(i)<\/strong><\/tt>unconditional! So when you see blocks of code that aren\u2019t in braces, you might sense just a tiny, wee, soup\u00e7on of uncleanliness which makes you uneasy.<\/p>\n OK, so far I\u2019ve mentioned three levels of achievement as a programmer:<\/p>\n 1. You don\u2019t know clean from unclean.<\/p>\n 2. You have a superficial idea of cleanliness, mostly at the level of conformance to coding conventions.<\/p>\n 3. You start to smell subtle hints of uncleanliness beneath the surface and they bug you enough to reach out and fix the code.<\/p>\n There\u2019s an even higher level, though, which is what I really want to talk about:<\/p>\n 4. You deliberately architect your code in such a way that your nose for uncleanliness makes your code more likely to be correct.<\/p>\n This is the real art: making robust code by literally inventing conventions<\/em> that make errors stand out on the screen.<\/p>\n So now I\u2019ll walk you through a little example, and then I\u2019ll show you a general rule you can use for inventing these code-robustness conventions, and in the end it will lead to a defense of a certain type of Hungarian Notation, probably not the type that makes people carsick, though, and a criticism of exceptions in certain circumstances, though probably not the kind of circumstances you find yourself in most of the time. <\/p>\n But if you\u2019re so convinced that Hungarian Notation is a Bad Thing and that exceptions are the best invention since the chocolate milkshake and you don\u2019t even want to hear any other opinions, well, head on over to Rory\u2019s and read the excellent comix<\/a> instead; you probably won\u2019t be missing much here anyway; in fact in a minute I\u2019m going to have actual code samples which are likely to put you to sleep even before they get a chance to make you angry. Yep. I think the plan will be to lull you almost completely to sleep and then to sneak the Hungarian=good, Exceptions=bad thing on you when you\u2019re sleepy and not really putting up much of a fight.<\/p>\n\n
\n
foo(i);<\/strong><\/tt><\/p>\n<\/blockquote>\n\n
bar(i);<\/span>
foo(i);<\/strong><\/tt><\/p>\n<\/blockquote>\n
![\"Somewhere](\"https:\/\/i0.wp.com\/www.joelonsoftware.com\/wp-content\/uploads\/2005\/05\/Umbria.jpg?w=730&ssl=1\")
<\/p>\n