{"id":316,"date":"2007-04-06T08:23:04","date_gmt":"2007-04-06T15:23:04","guid":{"rendered":"http:\/\/www.red-sweater.com\/blog\/316\/coding-for-readability"},"modified":"2007-04-07T08:28:11","modified_gmt":"2007-04-07T15:28:11","slug":"coding-for-readability","status":"publish","type":"post","link":"https:\/\/redsweater.com\/blog\/316\/coding-for-readability","title":{"rendered":"Coding For Readability"},"content":{"rendered":"<p>Raymond Chen today <a href=\"http:\/\/blogs.msdn.com\/oldnewthing\/archive\/2007\/04\/06\/2036150.aspx\">reminds us<\/a> that the readbility of code is important. But I&#8217;m not sure I agree with his headline\/premise: <\/p>\n<blockquote><p>\n&#8220;Code is read much more often than it is written.&#8221;\n<\/p><\/blockquote>\n<p>\nIn my opinion it&#8217;s more important for code to be <em>skimmable<\/em> than readable. This may be a lot of nitpicking over what is just supposed to be a catchy subject for Raymond&#8217;s blog, but I find it thought provoking. Let&#8217;s say you&#8217;ve got 100K of code. It&#8217;s OK if 90K of that code is <em>completely unreadable<\/em>, as long as it never needs to be modified again. That&#8217;s a big if, but my point is that the 10K that is actively developed can be well separated from the 90K of unreadable garbage, and you&#8217;re in good shape. Your code is skimmable. <\/p>\n<p>\nIn other words, don&#8217;t waste your time making already unreadable code &#8220;readable.&#8221; Just keep it in a dirty subroutine (and subfolder, probably!) where it belongs, and keep your high level code meaningful. I would guess that the vast majority of code in any shipping product has not been &#8220;read&#8221; in years. The products continue to evolve because they are skimmable. The change-prone portions have naturally eroded away from the giant clumps of unreadable junk.\n<\/p>\n<p>\nWhich isn&#8217;t to say that new code shouldn&#8217;t be as readable as possible. Interestingly enough, the article that prompted Raymond&#8217;s latest advice was an earlier one <a href=\"http:\/\/blogs.msdn.com\/oldnewthing\/archive\/2006\/08\/28\/728349.aspx\">advising against<\/a> BOOL parameters. He makes a good point, in recognizing that BOOL parameters in C or C++ do not often convey the parameter&#8217;s true meaning. Here is an area where Objective-C has a huge advantage with its inline-labeled parameters. Consider Raymond&#8217;s complaint:<\/p>\n<blockquote><p>\n&#8220;Even worse is that CreateEvent has two BOOL parameters. Like anybody reading the code later can remember which comes first.&#8221;\n<\/p><\/blockquote>\n<p>\nThe Windows API he alludes to has a prototype like this:\n<\/p>\n<pre>\n<code>\nHANDLE WINAPI\nCreateEvent(LPSECURITY_ATTRIBUTES lpEventAttributes, \n\t\t\t\tBOOL bManualReset,\n\t\t\t\tBOOL bInitialState,\n\t\t\t\tLPCTSTR lpName);\n<\/code><\/pre>\n<p>\nSo you end up with a call that looks like this:\n<\/p>\n<p><pre>\n<code>\nHANDLE myHandle = CreateEvent(myAttrs, TRUE, FALSE, \"Ouch\");\n<\/code><\/pre>\n<p>Indeed, Raymond was right. What do the TRUE and FALSE mean? The Objective-C equivalent of this CreateEvent method call would look more like:<\/p>\n<pre>\n<code>\nHANDLE myHandle = [self createEventWithAttributes:myAttrs\n\t\t\t\twithManualResetting:YES\n\t\t\t\tsignallingInitialState:NO\n\t\t\t\teventName:@\"Ahh...\"];\t\t\t\n<\/code>\n<\/pre>\n<\/p>\n<p>\nDamn it feels good to be a Cocoa programmer.\n<\/p>\n<p>\n<strong>Update:<\/strong> It occurred to me shortly after writing this that when I do write C code, I often overcome this problem by \/* inline-commenting *\/ the parameters. This technique was also described by somebody <a href=\"http:\/\/blogs.msdn.com\/oldnewthing\/archive\/2006\/08\/28\/728349.aspx#729978\">in the comments<\/a> on Raymond&#8217;s blog.\n<\/p>\n<p>\n<strong>Update 2:<\/strong> I didn&#8217;t think this post through too well before posting it, and now I feel like I&#8217;m suffering a bit of the fallout that comes from that. It&#8217;s easy to take from my post above that I have a nonchalant attitude about code readability. I meant it more as a riff on Raymond&#8217;s headline, and as an opportunity to add my belief that as important as readability is, skimmability is even more important.\n<\/p>\n<p>\nEric Albert wrote a <a href=\"http:\/\/outofcheese.org\/2007\/04\/07\/designing-for-readability\/\">thoughtful reply<\/a>, to which I was motivated to also reply in his <a href=\"http:\/\/outofcheese.org\/2007\/04\/07\/designing-for-readability\/#comment-888\">comments<\/a>. I think my thoughts there might be also serve the permanent record of this entry here:\n<\/p>\n<blockquote><p>\nFor the record, I am also in (nearly) complete agreement with Raymond. I mainly disagreed with his premise that code is read more often than it&#8217;s written. I don&#8217;t think that&#8217;s true.<\/p>\n<p>And my opinions about this also come from being a code generalist. In particular, I think of the bugs I fixed in the Mac OS 7-9 days, when some of the ugliest, unreadable code imaginable was involved in the fixing. Often it was the skimmability of the outer layers that made it possible to pinpoint a bug, even if the final fix required cracking open some C file that was autotranslated from Pascal that was auto-translated from 68K Assembly.<\/p>\n<p>In short: a giant code base is referenced much more like the yellow pages than like a novel. In the phone book, it&#8217;s nice when all of the entries are readable and well designed, but it&#8217;s much more important to be able ot skim to the section you&#8217;re most interested in right now.\n<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"<p>Raymond Chen today reminds us that the readbility of code is important. But I&#8217;m not sure I agree with his headline\/premise: &#8220;Code is read much more often than it is written.&#8221; In my opinion it&#8217;s more important for code to be skimmable than readable. This may be a lot of nitpicking over what is just [&hellip;]<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,34,15],"tags":[],"class_list":["post-316","post","type-post","status-publish","format-standard","hentry","category-cocoa","category-links","category-programming"],"_links":{"self":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/316","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/comments?post=316"}],"version-history":[{"count":0,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/316\/revisions"}],"wp:attachment":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/media?parent=316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/categories?post=316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/tags?post=316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}