Large Program Development

Prof. Brian D. Davison

Computer Science & Engineering, Lehigh University

Announcements

• Wednesday's class will be in the PL122 Sun lab
• New homework #3 online, due Friday
• Today's schedule
  • Return and review exam #1 solutions (Range 59-100, mean of 91)
  • Continue Large Program Development Issues

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...

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.

Homework

• Your homework for Friday will introduce you further to coding styles.