Large Program Development

Last time: Debugging

Prof. Brian D. Davison

Computer Science & Engineering, Lehigh University

Additional Credits

Announcements

• Homework #3 is assigned today and due Wednesday.
• Today's schedule
  • Continue Large Program Development Issues
  • Discuss debugging lab from last week, bus errors, segmentation faults
  • Discuss dynamic memory-checking

C Whitespace

• As you know, the C compiler does not care about indentation, line breaks, or other whitespace
• That doesn't mean you should not include it!
• The following are equivalent:

  for(i=0;i<10;i=i+1)printf("%d\n",i);
  

  and

         for (i = 0; i < 10; i = i + 1)
  printf("%d\n", i);
  

C Whitespace

• So are these:

for      (        i
=        0        ;
i        <        10
;        i        =
i        +        1
)        printf   (
"%d\n"   ,        i
)        ;

and

      for
     (i=0;
    i<10;i=
   i+1)printf
  ("%d\n", i);

C Obfuscation

• As you can imagine, C can be quite unreadable.
• There are regular contests for the best obfuscated C code...
• One anonymous entry, from 1984, reads

  int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
  o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
  

  and has since been used as a tatoo.
• Your code should only appear obfuscated when submitting to a contest!

Coding Style

• It is highly useful to adopt a consistent coding style
• Coding styles specify guidelines for
• File Organization
• Directory Organization
• Comments
• Declarations
• Whitespace
• Naming Conventions
• Conditional Compilation
• Debugging Conventions
• Writing for Portability
and many more...

Coding Style Comments

• From a discussion on Slashdot (tech blog/discussion board).
  "Code can never be 100% self documenting, but that's no reason to settle for 0%. Whether you use CamelCase or words_broken_with_underscores is a matter of style, and you should stick with the style of the code base you're working on.

  Anyone who can't or won't work with multiple languages or adopt the necessary style for an existing project is a poor programmer. When you create [a] project, you create the rules. When you work on someone else's project, you follow the rules."

Style Rules

• Some coding styles will distill their advice into simple rules
• Rule 1-3: Use white space to break a function into paragraphs.
• Rule 2-7: Comment your code as you write it.
• Rule 3-11: Follow every variable declaration with a comment that defines it.
• Rule 3-12: Whenever possible, include the units of measure in the description of a variable.
• Rule 4-14: Put the operator ++ and -- on lines by themselves. Do not use ++ and -- inside other statements.
• Rule 4-15: Never put an assignment statement inside any other statement.
• Rule 5-20: End every case in a switch with a break or the comment /* Fall Through */
• Rule 6-2: Constant names are all upper-case.
• Rule 8-3: Don't let users do something stupid without warning them.

Looking ahead

• Homework #3 introduces you further to coding styles.