Large Program Development

Last time: Debugging

Prof. Brian D. Davison

Computer Science & Engineering, Lehigh University

Announcements

• Reminder: homework #3 online, due Friday
• New: Project 4 is now online, due next Thursday (3/1).
• Today's schedule
  • Continue Large Program Development Issues
  • Return and review exam #1 solutions

Defensive Programming

• The larger your project, the more difficult it will be to find subtle errors
• The best approach is to code defensively
• Check every function for failure codes (especially system calls)
• Initialize all variables, especially pointers
• Write testing harnesses for all functions
• Document carefully -- e.g., describe all assumptions for values passed as parameters to your functions
• Verify that parameters are valid before using them
• Use assert(3c) liberally to enforce those assumptions

Using assert()

• In general, we want coding errors to cause the application to fail as quickly as possible so that they can be more easily detected during debugging.
• C provides a standard assert(3c) macro, which evalutes the expression passed in, and if false, outputs an error message and calls abort(3c)

#include <assert.h>

...
assert(status == 0);

• Failures would look something like:

  % ./program
  source.c:114: failed assertion `status == 0'
  Abort
  %
  

When to use/not use assert()

• Use assert() anywhere that a coding error might cause an invalid condition
  • e.g., when your code is called by someone else!
  • or when one module calls another
• Don't use assert() to validate user input
• since assert causes the program to fail, rather than politely generating an appropriate error message and permitting the user to re-enter valid input
• Don't use assert() when you can recover gracefully
  • Such as when trying to open a file without proper permissions

C Whitespace

• As most of 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.
• Project 4 is about debugging.
• Friday's quiz will be on the preprocessor and debugging