{"id":3649,"date":"2017-09-10T05:00:18","date_gmt":"2017-09-10T05:00:18","guid":{"rendered":"http:\/\/www.nikola-breznjak.com\/blog\/?p=3649"},"modified":"2017-09-05T22:06:54","modified_gmt":"2017-09-05T22:06:54","slug":"code-complete-2-steve-mcconnell-pseudocode-programming-process","status":"publish","type":"post","link":"https:\/\/nikola-breznjak.com\/blog\/books\/programming\/code-complete-2-steve-mcconnell-pseudocode-programming-process\/","title":{"rendered":"Code Complete 2 \u2013 Steve McConnell \u2013 Pseudocode Programming Process"},"content":{"rendered":"<p>I just love Steve McConnell&#8217;s classic book <a href=\"http:\/\/amzn.to\/2vdwv5v\">Code Complete 2<\/a>, and I recommend it to everyone in the Software &#8216;world&#8217; who&#8217;s willing to progress and sharpen his skills.<\/p>\n<p>Other blog posts in this series:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.nikola-breznjak.com\/blog\/books\/programming\/code-complete-2-steve-mcconnell-part-1-laying-foundation\/\">Part 1 (Chapters 1 &#8211; 4): Laying the Foundation<\/a><\/li>\n<li><a href=\"http:\/\/www.nikola-breznjak.com\/blog\/books\/programming\/code-complete-2-steve-mcconnell-design-construction\/\">Chapter 5: Design in Construction<\/a><\/li>\n<li><a href=\"http:\/\/www.nikola-breznjak.com\/blog\/books\/programming\/code-complete-2-steve-mcconnell-working-classes\/\">Chapter 6: Working Classes<\/a><\/li>\n<li><a href=\"http:\/\/www.nikola-breznjak.com\/blog\/books\/programming\/code-complete-2-steve-mcconnell-high-quality-routines\/\">Chapter 7: High-Quality Routines<\/a><\/li>\n<li><a href=\"http:\/\/www.nikola-breznjak.com\/blog\/books\/programming\/code-complete-2-steve-mcconnell-defensive-programming\/\">Chapter 8: Defensive programming<\/a><\/li>\n<\/ul>\n<p>The benefits you can expect from using the pseudocode:<\/p>\n<ul>\n<li>makes reviews easier &#8211; you can review detailed designs without examining the source code<\/li>\n<li>supports the idea of iterative refinement<\/li>\n<li>makes changes easier &#8211; a few lines of pseudocode are easier to change than a page of code<\/li>\n<li>it&#8217;s easier to maintain than other forms of design documentation<\/li>\n<\/ul>\n<h2>Steps in building a routine<\/h2>\n<ol>\n<li>Design the routine<\/li>\n<li>Code the routine<\/li>\n<li>Check the code <\/li>\n<li>Clean up loose ends<\/li>\n<li>Repeat as needed <\/li>\n<\/ol>\n<h2>1. Design the routine<\/h2>\n<ul>\n<li>Check the prerequisites to see that the job of the routine is well defined and fits cleanly into the overall design<\/li>\n<li>Define the problem the routine will solve<\/li>\n<li>Name the routine &#8211; good routine names are one <strong>sign of a superior program<\/strong> and they&#8217;re not easy to come up with<\/li>\n<li>Decide how to test the routine<\/li>\n<li>Research functionality available in the standard libraries &#8211;  the single biggest way to improve both the quality of your code and your productivity is to <strong>reuse good code<\/strong><\/li>\n<li>Think about error handling &#8211; think about all the things that could possibly go wrong in the routine<\/li>\n<li>Think about efficiency &#8211; in a vast majority of systems, efficiency isn&#8217;t critical. Design your routine so that it will meet its resource and speed goals<\/li>\n<li>Research the algorithms and data types &#8211; if functionality isn&#8217;t available in the available libraries, it might still be described in an algorithms book<\/li>\n<li>Write the pseudocode &#8211; you might not have much in writing after you finish the preceding steps. The main purpose of the steps is to establish a mental orientation that&#8217;s useful when you actually write the routine<\/li>\n<li>Think about the data<\/li>\n<li>Check the pseudocode &#8211; once you&#8217;ve written the pseudocode and designed the data, take a minute to review the pseudocode you&#8217;ve written. Back away from it, and think about <strong>how you would explain it to someone else<\/strong><\/li>\n<li>Try a few ideas in pseudocode, and keep the best (iterate)<\/li>\n<\/ul>\n<h2>2. Code the routine<\/h2>\n<ul>\n<li>Start with pseudocode <\/li>\n<li>Write the routine declaration\n<ul>\n<li>Turn the original header  comment into a programming-language code comment above declaration <\/li>\n<\/ul>\n<\/li>\n<li>Write the first and last statements, and turn the pseudocode into high-level comments<\/li>\n<\/ul>\n<pre><code>    \/* Header comment about what routine does *\/\n    Status ReportErrorMessage(\n        ErrorCode errorToReport\n    ) {\n        \/\/set the default status to \"fail\"\n\n        \/\/if the error code is valid, display the error message \n        \/\/and declare success\n\n        \/\/if the error code isn't valid, notify the user that an internal \n        \/\/error has been detected\n\n        \/\/return status information\n    }\n<\/code><\/pre>\n<ul>\n<li>Fill in the code below each comment <\/li>\n<\/ul>\n<pre><code>\/* Header comment about what routine does *\/\nStatus ReportErrorMessage(\n    ErrorCode errorToReport\n) {\n    \/\/set the default status to \"fail\"\n    Status errorMessageStatus = Status_Failure;\n\n    \/\/if the error code is valid, display the error message \n    \/\/and declare success\n    if ( errorMessage.ValidCode() ) {\n        DisplayMessage( errorMessage.Text() );\n        errorMessageStatus = Status_Success;\n    }\n\n    \/\/if the error code isn't valid, notify the user that an internal \n    \/\/error has been detected\n    else {\n        DisplayMessage( \"Internal Error: Invalid error code in ReportErrorMessage()\" );\n    }\n\n    \/\/return status information\n    return errorMessageStatus;\n}\n<\/code><\/pre>\n<blockquote><p>\n  Each comment should normally expand to about 2 to 10 lines of code.\n<\/p><\/blockquote>\n<h2>3. Check the code<\/h2>\n<ul>\n<li>Mentally check the routine for errors<\/li>\n<\/ul>\n<blockquote><p>\n  A working routine isn&#8217;t enough. If you don&#8217;t know why it works, study it, discuss it, and experiment with alternative designs until you do.<\/p>\n<p>  Compile the routine after reviewing it. It might seem inefficient to wait this long to compile. You&#8217;ll benefit in several ways, however, by not compiling until late in the process. After the first compile, you step up the pressure: &#8220;I&#8217;ll get it right with just one more compile.&#8221; The &#8220;Just One More Compile&#8221; syndrome leads to hasty, error-prone changes that take more time in the long run.\n<\/p><\/blockquote>\n<ul>\n<li>Step through the code in the debugger<\/li>\n<li>Test the code<\/li>\n<\/ul>\n<h2>4. Clean up leftovers<\/h2>\n<ul>\n<li>Check the routine&#8217;s interface. Make sure that all input and output data is accounted for and that all parameters are used<\/li>\n<li>Check for general design quality. Make sure the routine does one thing and does it well, that it&#8217;s loosely coupled to other routines, and that it&#8217;s designed defensively<\/li>\n<li>Check the routine&#8217;s variables (inaccurate variable names, unused objects, undeclared variables, and so on)<\/li>\n<li>Check routine&#8217;s statements and logic<\/li>\n<li>Remove redundant comments<\/li>\n<\/ul>\n<h2>Alternatives to the PPP<\/h2>\n<ul>\n<li><strong>Test-first development<\/strong> &#8211; popular development style in which test cases are written before writing any code<\/li>\n<li><strong>Refactoring<\/strong> &#8211; development approach in which you improve code through a series of semantic preserving transformation<\/li>\n<li><strong>Design by contract<\/strong> &#8211; development approach in which each routine is considered to have preconditions and postconditions <\/li>\n<li><strong>Hacking?<\/strong> &#8211; some programmers try to hack their way toward working code rather than using a systematic approach like the PPP. If you&#8217;ve ever found that you&#8217;ve coded yourself into a corner in a routine and have to start over, that&#8217;s an indication that the PPP might work better<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>I just love Steve McConnell&#8217;s classic book Code Complete 2, and I recommend it to everyone in the Software &#8216;world&#8217; who&#8217;s willing to progress and sharpen his skills.&hellip;<\/p>\n","protected":false},"author":1,"featured_media":3572,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[34],"tags":[],"class_list":["post-3649","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts\/3649","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/comments?post=3649"}],"version-history":[{"count":1,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts\/3649\/revisions"}],"predecessor-version":[{"id":3650,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/posts\/3649\/revisions\/3650"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/media\/3572"}],"wp:attachment":[{"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/media?parent=3649"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/categories?post=3649"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nikola-breznjak.com\/blog\/wp-json\/wp\/v2\/tags?post=3649"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}