Background:
As Kurt has mentioned in lecture, it's very important for your code to
be understandable.  Writing your code with good style is the first
step to writing understandable code.  So what goes into good style?
Well, there are many things, but here are the ones that these
guidelines will address:

Guidelines:
o Understandable parameter and function names.  You should always name
  your top-level functions according to what is specified in the
  homework.  Helper functions may be named however you choose, but
  make sure that they convey meaningful informatin about exactly what
  they do, such as:
       
       ; top level function
       (define (zoo-keeper...
       
       ;helper functions
       (define (sweep-cages...
       (define (feed-monkeys...

  Make sure that your parameters have meaningful names.  If you're
  taking in a list of names, then "name-list" would be a good
  parameter name.  "foo" or "a" or "l" are poor choices because they
  convey no useful information about what it is that they are
  placeholders for.  

o Code formatting.  Utilize the homework template so that your name
  and gt-number are in the correct places.  This is just like putting
  your name on a test or any other document.  Sure, we can figure out
  just who you are buy looking at the turning data, but when we're
  looking at your file, we want to be able to easily see who you are,
  what your gt-number is, what assignment we're looking at, etc...

  Code indentation is another important part of formatting.
  Dr. Scheme has some powerful features built into its definitions
  window.  One of them is the ability to automatically indent your
  code for you.  Putting the curser on any line and hitting the TAB
  key will automagically indent that line.  Use this feature.  Also,
  please refrain from declaring a function entirely on one line like
  this:
  (define (square number) (* number number))
  
  It's much easier to read like this:
  (define (square number)
    (* number number))
  
  Format your essay/short answers like this:

  ;;; p13.
  ; This is my essay answer.  Note that it begins on the line
  ; following the problem number tag.  Note also the single semi-colon 
  ; which proceeds every line.  Also notice the single space between
  ; the semi-colon and the beginning of the sentence.  See how this
  ; makes for an easy to read block of text?  See how the spelling and
  ; grammar are mostly correct?  Isn't it much easier to read than:
  ;
  ;   ;;; p42. this is my answer.  i don't like to make myc ode easy
  ;   ;;;to readand i don't even look over teh answer for common
  ;   ;;;mispelinngs adn typos.  eye am a 733t k0d3-munk3y, ru?

  That last bit is horrible.  Just because you're writing programs
  doesn't mean that you should throw spelling and grammar out of the
  window. 

  Also, please put a blank line between functions declarations and a
  few (like two or three) between the end of a function and the next
  ;;; p#. tag.
  
o Comment your code.  This is a very basic and very important habit to
  pick up.  Comments should explain why and what your code is doing.
  They should be thorough, to the point, and placed nicely in the
  code.  Here's a good comment:

  ;;; p2000.
  ; my-remainder-ag mimics the functionality of the built in function 
  ; remainder.  It takes in two parameters: the dividend and the
  ; divisor, and it returns the value of the remainder when the
  ; dividend is divided by the divisor.
  (define (my-remainder-ag dividend divisor)
    (.......

  Here's a relatively useless comment:
  
  ;;; p96.
  ; this function does stuff using that method we talked about that
  ; bad stuff happens sometimes, but i'm not sure when.  i don't
  ; really understand, so as far as i can tell it's all run by voodoo
  ; and chewing gum.

Epilogue:
Some of you may be wondering why we're making you follow these
guidelines.  After all, an uncommented, one-line,
single-character-parameter function is just as useful as a
well-commennted, easy to read, meaningfully-named-parameter function,
right?  Wrong.  Absolutely, positively, without a doubt wrong.  The
fact that your code functions is nice, but what if something changes?
What if the client decides he wants red text instead of blue?  What if
the web server changes names?  What if your company gets sued and you
have to take your code to court and stand up in front of a jury of
average citizens and explain how your illegible, chicken-scratch,
obfuscated code made an airplane fall out of the sky?  None of these
will be happy situations if your code is unreadable.  

Or, if you like to think about it in more immediate terms, consider
this:

Imagine you are a new employee at a company called cs1311X.  Imagine
that the bunch of TA's who lurk in the back of lecture are your
supervisors.  Imagine that your work is going to be evaluated to
decide whether or not to keep you on or to send you down the street to
burger-barn.  If your boss tells you to use a certain format for your
code, you can follow the directions and have your boss pleased with
you, or you can do your own thing, make up your own guidelines, have
you code be difficult to deal with because it's not like anybody
else's.  You can protest to mister-pointy-hair all you want, but he's
not going to care if your way is 'better' or 'more efficient,' he's
going to care that your code doesn't fit the specification, and he's
going to recommend that you apply for a job at a little farm school
that's just down the road.

However you choose to think about it, good style key to success, and
following these relatively simple guidelines will put you well on your
way.