{"id":38,"date":"2005-06-22T16:39:38","date_gmt":"2005-06-22T07:39:38","guid":{"rendered":"https:\/\/regex.info\/blog\/2005-06-22\/38"},"modified":"2005-06-22T16:41:15","modified_gmt":"2005-06-22T07:41:15","slug":"the-coding-commands-according-to-dr-bergeron","status":"publish","type":"post","link":"https:\/\/regex.info\/blog\/2005-06-22\/38","title":{"rendered":"The (Coding) Commands According to Dr. Bergeron"},"content":{"rendered":"

In my first semester at grad school<\/a>\n(wow, now 18 years ago... I'm old), all CS master's students were required\nto take two intensive “this is what you should have learned during undergrad<\/i> classes”, CS801<\/b> (theory) and CS802<\/b>\n(practice). The latter<\/span> was taught by Dr. Dan Bergeron<\/a>, who was\n— and probably still is — an excellent teacher, but whom I remember<\/span> most\nas a man<\/span> of stellar integrity and fairness — a good<\/span> father-figure that\nmost collegiate environments lack.\n\n<\/p>

Anyway, while rummaging around some old papers the other day, I found<\/span> this handout on “coding commandments” from the class. (It\nseems that programming in the class was done in Pascal<\/a>\n— ugh.) The commandments are still as relevant today as then (well,\nperhaps the last one is more “advice” than\n“commandment”, and about some others, I do remember<\/span> bristling\nat some of them, but I no<\/span> longer remember which.)\n\n<\/p>

I thought some of you might enjoy this, so pass it along...\n\n<\/p>
\n

Coding Commandments
CS802 - Fall 1987 October 30,<\/span> 1987 <\/p>

\n\nThe programming style conventions listed below shall<\/b> be followed for\nprograms submitted in this course. I firmly<\/span> believe programs that follow\nthese guidelines are more readable, more comprehensible and more\nmaintainable than programs that do not follow the conventions. Furthermore,\nthese conventions are consistent with well-established philosophies that\ndefine what constitutes good software engineering and are not just my\nidiosyncrasies (in spite of the fact that lots of existing software does\nnot follow these guidelines). Finally, I will be<\/span> the last to claim that\nthere are no circumstances in which these guidelines should be violated.\n(In this course, however, there will be no exceptions!)<\/p><\/td><\/tr>\n\n

(1)  <\/p><\/td>

Every\nprocedure\/function shall have exactly 1 return<\/b> statement and that\nstatement will appear at the bottom of the procedure as the last executable\nstatement of the procedure. <\/p><\/td><\/tr>

(2)  <\/p><\/td>

Every identifier used\nin the program shall have an associated comment that describes what the\nfunction of the identifier is. This includes symbolic constants, types,\nfields in records, parameters, variables, etc.\n\n<\/p><\/td><\/tr>

(3)  <\/p><\/td>

Every\nprocedure\/function shall be preceded by a clear<\/span> separator (such as a row<\/span> of\nasterisks or dashes or whatever) with a clear<\/span> indication of the procedure\nname and a brief<\/span> comment describing the essential function provided by that\nfunction.\n\n<\/p><\/td><\/tr>

(4)  <\/p><\/td>

A long\nprocedure is a bad procedure. All the code<\/span> for a procedure<\/span> should fit on no\nmore than one page, so that it can be readily comprehended by a reader.<\/span>\n\n<\/p><\/td><\/tr>

(5)  <\/p><\/td>

Indentation of code is a\nvery important tool in producing understandable code in which the control\nflow is readily discernible. Use good indentation<\/span> that clearly shows the\ncontrol flow. Don't let comments or debugging code obscure the indentation.\nDon't indent more than 2-4 blanks per nesting level.\n\n<\/p><\/td><\/tr>

(6)  <\/p><\/td>

Use a\nblank line to clearly identify major loop or conditional statements. A brief<\/span> comment at the end of the line with the statement keyword is also\nvery helpful if it tells at a high<\/span> level what the statement does. If you have<\/span> a loop<\/span> or conditional that covers more than 8 lines or so, make sure\nthat the end<\/b> statement includes a comment<\/span> that identifies which\nstatement is being ended. If there<\/span> are nested statements of the same type,\nbe sure to include enough information to clearly identify the right one.\n(For example, end { while i <> 0 }<\/b>)\n\n\n<\/p><\/td><\/tr>

(7)  <\/p><\/td>

If you\nhave an if-then-else<\/b> statement with 1 short alternative and one long\nalternative, arrange the condition so that the short alternative is the\nthen<\/b> clause, and the long one is the else<\/b>.\n\n<\/p><\/td><\/tr>

(8)  <\/p><\/td>

Use\nnested else-if<\/b> in preference to nested then-if<\/b>.\n\n<\/p><\/td><\/tr>

(9)  <\/p><\/td>

Every\nloop should have exactly one exit. Do not use<\/span> a loop<\/b> statement if a\nwhile<\/b> or repeat<\/b> is what you mean.\n\n<\/p><\/td><\/tr>

(10)  <\/p><\/td>

Use\nmeaningful variable names.\n\n<\/p><\/td><\/tr>

(11)  <\/p><\/td>

Use\nsymbolic constants excessively.\n\n<\/p><\/td><\/tr>

(12)  <\/p><\/td>

If\nyou use arrays, you must always check the index for exceeding the bounds\nbefore trying to access the array element indicated by the index.\n\n<\/p><\/td><\/tr>

(13)  <\/p><\/td>

If\nyou use lists, use a dummy sentinel<\/i>, so that no list is ever empty.\nGenerally, it is also wise to always have a tail<\/span> pointer for efficiency of\nsearch and addition to the list. For searching, store the key you wish to\nsearch for in the tail (which is the sentinel), so that you are guaranteed\nto find it. Finally, if you are bothering to implement a list<\/span> at all, you\nmight as well implement two-way lists. The extra<\/span> overhead of having the\nback<\/i> pointer is insignificant and it makes deletion much easier.\n\n<\/p><\/td><\/tr><\/table><\/td><\/tr><\/table>\n","protected":false},"excerpt":{"rendered":"

In my first semester at grad school (wow, now 18 years ago... I'm old), all CS master's students were required to take two intensive \"this is what you should have learned during undergrad classes\", CS801<\/b> (theory) and CS802<\/b> (practice). The latter was taught by Dr. Dan Bergeron, who was -- and probably still is -- an excellent teacher, but whom I remember most as a man of stellar integrity and fairness -- a good father-figure that most collegiate environments lack. <\/p>

Anyway, while rummaging around some old papers the other day, I found this handout on \"coding commandments\" from the class. [...]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"_links":{"self":[{"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/posts\/38"}],"collection":[{"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/comments?post=38"}],"version-history":[{"count":0,"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/posts\/38\/revisions"}],"wp:attachment":[{"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/media?parent=38"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/categories?post=38"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regex.info\/blog\/wp-json\/wp\/v2\/tags?post=38"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}