{"id":2353,"date":"2015-08-14T17:27:55","date_gmt":"2015-08-14T05:27:55","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2353"},"modified":"2015-08-14T17:30:37","modified_gmt":"2015-08-14T05:30:37","slug":"formatting-case-statements","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2353\/","title":{"rendered":"Formatting Case Statements"},"content":{"rendered":"[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span>

I’m afraid I have been guilty of editorialising on StackOverflow. It was sheer laziness really. A question prompted me to respond by sharing a personal preference and instead of “context switching” to my blog I posted an answer that even at the time I acknowledged was not<\/em> in fact an answer (though as transgression go I have to say I have seen far worse, but, that’s no excuse).<\/p>\n

So, with (further) apologies to StackOverflow, I have withdrawn that answer and instead present that editorial here, a more appropriate forum.<\/p>\n

<\/p>\n

The question involved how to cajole, coerce or otherwise convince the source formatting tools in RAD Studio to format a case<\/strong> statement in a manner pleasing to the OP<\/a>. For illustration in the question they posted an example of how RAD Studio was currently formatting the statement (I hope they don’t mind me reproducing their examples here):<\/p>\n

\r\n    case SomeEnum of\r\n      seOne: begin\r\n\r\n        end;\r\n      seTwo: begin\r\n\r\n        end;\r\n      seThree:\r\n        ;\r\n      seFour:\r\n        DoSomething;\r\n    end;\r\n<\/pre>\n
And helpfully then illustrated how they would prefer to have it formatted:<\/p>\n
\r\n    case SomeEnum of\r\n      seOne: begin\r\n\r\n      end;\r\n      seTwo: begin\r\n\r\n      end;\r\n      seThree: ;\r\n      seFour: DoSomething;\r\n    end;\r\n<\/pre>\n
It just happens that case<\/strong> statements were among the last aspects of my own personal Delphi coding style to really settle down over the past mumble<\/em> years.  But in more recent years I felt I finally cracked it, having finally settled on a consistent formatting style (keyword: “style<\/em>“, not<\/strong> “solution<\/em>“) that once alighted upon has stood the test of time in a way that my previous efforts did not.<\/p>\n
I may even have first come across this style – or something significantly similar – in someone else’s code, but if so I have long since forgotten.  If you recognise this style and feel it has been appropriated without proper attribution, apologies.  It is not intentional.<\/p>\n
And so with too much ado already, here it is…<\/p>\n
\r\n    case SomeEnum of\r\n\r\n      seOne   : begin\r\n\r\n                end;\r\n\r\n      seTwo   : begin\r\n \r\n                end;\r\n\r\n      seThree : { NO-OP };\r\n\r\n      seFour  : DoSomething;\r\n\r\n      seFive,\r\n      seSix   : DoSomethingElse;\r\n\r\n    else\r\n      \/\/ TODO: How to handle the unhandled.. ?\r\n    end;\r\n<\/pre>\n
As you can see, I took the original code and added slightly to it, allowing me to illustrate how I deal with multiple cases having common behaviour (seFive<\/strong> and seSix<\/strong>) and (for this revised and extended blog post) an else<\/strong> statement.<\/p>\n
Among the reasons this formatting finds favour with me are:<\/p>\n
    \n
  1. The conditional statements have appropriately equal indentation with respect to each other, the single exception to this being any “else” case, where present.<\/li>\n
  2. High visibility of the case values, often key to understanding such code when you come to read it months\/years later.<\/li>\n
  3. It’s clean and clear – highly readable (to me).<\/li>\n<\/ol>\n
    In addition to the case formatting I also demonstrate my practice of providing a specific comment to indicate a deliberate and explicit NO-OP<\/strong> as distinct from an equally explicit TODO<\/strong> (in the else<\/strong>).  You could choose to be explicit about either one and interpret the absence of such any explicit indication as implying the other, but this leaves open the possibility that what is then interpreted as “implied” is in reality an oversight<\/em> (is it a no-op<\/em> or an unannotated to-do<\/em> ?  or vice-versa contrariwise).<\/p>\n
    In ay event, no amount of tweaking will convince RAD Studio to determine the difference, let alone add the appropriate comments for you (though some static analysis tools may draw attention to “null” statements and some may even be able to be configured to identify explicitly deliberately null statements, where commented as such).<\/p>\n
    But as for the case statement in general, I’m not presenting this as the<\/em> or even a<\/em> ideal or perfect approach, merely sharing my personal, individual preference that has evolved over the years.<\/p>\n
    At the end of the day, whatever works for you works for you. \ud83d\ude42<\/p>\n
    Footnote<\/h2>\n
    Sertac Akyuz provided Jerry with the answer he was looking for.  \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
    [Estimated Reading Time: <\/span>  3<\/span> minutes]<\/span><\/span>I’m afraid I have been guilty of editorialising on StackOverflow. It was sheer laziness really. A question prompted me to respond by sharing a personal preference and instead of “context switching” to my blog I posted an answer that even at the time I acknowledged was not in fact an answer (though as transgression go […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[4],"tags":[125,291,13,173,290],"class_list":["post-2353","post","type-post","status-publish","format-standard","hentry","category-delphi","tag-case","tag-formatting","tag-language","tag-pascal","tag-syntax"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-BX","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2353","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=2353"}],"version-history":[{"count":7,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2353\/revisions"}],"predecessor-version":[{"id":2360,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2353\/revisions\/2360"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2353"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2353"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2353"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}