How to Pass This Course

CS 509 - Advanced Programming II, Fall 2002

What Happened Last Time

Be a Good Student

• Follow directions

• Exhibit learning behavior

  • Mistakes

• Schedule your time wisely

• Work in groups

Follow Directions

• Testing is automated.

  If you don't follow directions, your tests will fail and so will you.

• Input

  • Understand std-in, std-out, and command-line arguments.

  • Do not prompt for input.

• Do you want to deal with someone who can't follow directions?

Output

• Follow the output format.

  • Specified:

    Output rectangles one per line with the format x₁ y₁ x x₂ y₂.

  • Implemented:

    THIS SI FINAL DISPLAY OF AN ARRAY 
    {[ 1, 1 ], [ 3, 3 ]}  Level is : 0 Position is : 0
    {[ 2, 2 ], [ 4, 4 ]}  Level is : 1 Position is : 0
    

• Debugging output.

  • Send debugging output to std-err (cerr).

  • Turn off debugging output in submissions.

• Testing is automated.

Exhibit Learning Behavior

• Penalties increase as time goes on.

  • The penalty for buffer-overflow errors grows quickly.

  • The penalty for old errors grow quickly.

• Frowned upon behavior should decrease over time.

• If you read about it, and we talk about it, I should see it in your code.

• For example: including .cc files.

  #include "my-list.cc"
  

  • Unconventional, screws up compilation.

  • The first time I may rewrite it.

  • The second time it'll loose points.

"But Everybody Makes Mistakes."

• That's true, expected, and important.

• But, make mistakes where it doesn't hurt you.

  • Making mistakes when you enter book programs is good.

  • Making mistakes when you study with friends is good.

  • Making mistakes on tests is bad.

  • Making mistakes in assignments is bad.

• It's like music - you make mistakes, but not on stage.

• Exhibit learning behavior.

  The road to wisdom?
  Well it's plain and simple to express:
  err and err and err again
  but less and less and less.

  ---- Piet Hein

Use Your Time Wisely

• Make sure you schedule your time wisely.

  Date: 29 Oct 2001 11:29:37 -0500
  From: "R. Clayton" <rclayton@monmouth.edu>
  To: s0------@monmouth.edu
  Subject: Assignment deadline.
  
    I've had a report, a project, a mid-term test 
    and your assignment due this week.  Can I get an 
    extension on the assignment?
  
  No, sorry - no extensions.
  

• I generally don't extend individual deadlines.

  Date: 14 Dec 2001 13:41:19 -0500
  From: "R. Clayton" <rclayton@monmouth.edu>
  To: s0------@monmouth.edu
  Subject: Re: assignment 7
  
    Since these are the final days of the semester, 
    every deadline seems to come together at once. 
    Could we have an extension for the final assignment 
    for CS-509.
  
  Sorry, no deadline extensions.
  

Other Bits of Advice

• Design before you implement.

  • Know what you're implementing.

• Work in groups of two or three.

  • Design and evaluate the design.

  • Implement alone.

  • Test the implementation.

• Go back and review.

  • You're learning new things - how do they help?

  • You're going to be seeing your mistakes again.

  • It's like music: practice makes perfect.

Be a Good Programmer

• You're going to be a professional - act like one.

• Know your tools.

• Test your code.

• Documentation.

Know Your Tools

• Stream I-O.

  • Don't duplicate function.

    • What is going on here?

      
      void eat_white() {
        while (cin && isspace(cin.peek()))
        cin.ignore();
        }
      
      void f() {
        while(cin && (cin.peek() != EOF)) {
          cin >> s;
          eat_white();
          }
        }
      
      

  • Understand error and exceptional conditions.

    • Understand and use correctly the end-of-file condition.

• Know your libraries.

  • Unix has a lot of them, and they are here to help you.

  • C++ libraries can get complicated (stream io).

Test Your Code

• Don't rely on only my tests.

• Work in teams, test each other's code.

• Important for those programming on other systems.

  • Microsoft is more forgiving (read "non-standard") than is Solaris.

  • Disable Microsoft extensions; use strict ANSI-ISO compatibility.

• Code that core dumps loses big points.

  • Your program should handle empty input properly.

    • $ program < /dev/null

  • Your program should handle garbage input properly.

    • $ program < program

  • "Properly" means without core dumping.

The Vexing Question of Documentation

• Document your programs and code.

  • What are you trying to do?

  • How are you trying to do it?

• Make sure your comments are helpful.

  • Bad:

    // main function
    int main() {
    
    count = 0; // make counter to zero
    
    // Break the loop if temp_sum >= sum_of_vec
    
    while (temp_sum < sum_of_vec) {
    

  • Better:

    // Find the largest sub-sum less than the total.
    
    while (temp_sum < sum_of_vec) {
    

  Don't stress out over documentation.

  • But don't forget about it, either.

  ---

  My Documentation Style

  • I prefer a minimial documentation style.

  • Write short, complete comments for files and code.

    • // Represent expressions as binary trees.

    • // Insert the constant value n into the tree.

  • Emphasize purpose, not method.

    • Purpose should be simple, complete, and correct.

    • Method should be obvious from the code.

    • But, tricky methods should be documented.

  • Documentation is a coding clue.

    • If you can't write a short, complete sentence
      your code's probably not well written.

  ---

  General Programming Tips

  • Dynamic memory - don't don't do it.

  • Code size.

  • No magic numbers.

  ---

  Dynamic Memory is Not Your Friend

  • Make sure you need it.

    
    char *temp = new char[5];
    strcpy(temp,"<FONT");
    char *temp2 = new char[5];
    
    

  • If you do need it, use it correctly.

    
    bool readInst(List *L, char *&inst, int noInst) {
    
      char * line = new char[80];
      inst = new char[80];
      strcpy(inst, "\0");
    
      line = L->getNext();
      if ( line  == NULL )
        inst = NULL;
        return false;
      }
    
    

  • If you allocate it, free it.

    • Falling of the end of main() is not freeing storage.

  • I'll be watching.

    • Programs are tested with limited amounts of storage.

    • Programs are tested with debugging storage allocators.

  ---

  Big Code is Bad Code

  • Big code (big functions, big programs) are trouble.

    • Hard to understand.

    • Hard to create.

    • Hard to maintain.

  • You are responsible for every line of code you write.

    • Every array access, every pointer reference, all of it.

    • The less you write, the smaller your responsibility.

  • My rules of thumb.

    • More than 25 lines is a big procedure.

    • More than 10 procedures is a big file.

    • File count doesn't matter.

  ---

  Write Small Code

  • For example.

    void main() {
      LList list;
    
      cout << "Please enter a sequence of sets of "
           << "algebraic eq. (ctrl+d) to end" << endl;
    
      int setCount = readInput(list);
      printResults(list, setCount);
      }
    

    or

    

  ---

  ---

  Use Named Constants

  • A magic number just appears in code with no explanation.

    • What does this code do?

      
      int ans = check(s.substr(i,j-i));
           if (ans == 1) { /* whatever */ }
      else if (ans == 2) { /* whatever */ }
      else if (ans == 3) { /* whatever */ }
      else if (ans == 4) { /* whatever */ }
      else if (ans == 5) { /* whatever */ }
      else if (ans == 6) { /* whatever */ }
      else if (ans == 0) return false;
      
      

  • Magic numbers are hard to understand, use, and change. Avoid them.

  • Replace magic numbers with named constants.

    
    #define INVALID  0
    #define NUMBER   1
    #define VARIABLE 2
    #define OPERATOR 3
    #define LB       4
    #define RB       5
    #define EQUAL    6
    
    if (StBlk[row][0].Type() != VARIABLE) /* . . . */
    if (StBlk[row][col].Type() == INVALID) /* . . . */
    if ((StBlk[row][col].Type() == NUMBER ||
         StBlk[row][col].Type() == VARIABLE) &&
        (StBlk[row][col+1].Type() == LB)) /* . . . */
    if (StBlk[row][col].Type() == EQUAL) /* . . . */
    if (StBlk[row][1] .Type() != EQUAL) /* . . . */
    
    

  ---

  Other Programming Tips

  • Don't use system().

    • It is dangerous, unreliable, and expensive.

    • system() will be broken for testing.

  • Don't abuse files.

    • They are unreliable and expensive.

    • Files will be limited for testing.

  • Avoid dynamic memory; use dynamic memory correctly.

  • You are responsible for every array access.

    • A[-1] is never correct.

    • Neither is A[4294967295].

  • I'll be checking your container acccesses too.

    • Use the Safer STL library.

  ---

  This page last modified on 5 September 2002.