Some Tips for Passing This Course

CS 509 - Advanced Programming II, Spring 2002

What Happened Last Time

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.

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

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

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

• I generally don't extend individual deadlines.

  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.
  

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.

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

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;
      }
  
    // blah blah blah
    }
  

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

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:

    // Loop while the temporary sum is less than 
    // the vector sum.
    while (temp_sum < sum_of_vec) {
    

    or just

    while (temp_sum < sum_of_vec) {
    

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.

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 right, 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

  

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 looses big points.

  • Your program should handle empty input properly.

  • Your program should handle garbage input properly.

  • "Properly" means without core dumping.

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

This page last modified on 21 February 2002.