Section 3 with Remik (rz33@cornell.edu) 
Meeting #12 Notes
===========================================================
Administrivia
===========================================================
+ Trouble with HW #3 submissions; please verify that your
  submission was not corrupted (see cs212 site for details)

===========================================================
Review
===========================================================
+ Anti-RAD Software Engineering
+ Preventing buggy code

===========================================================
Anti-RAD Software Engineering
===========================================================
  Some time ago the term RAD was the hottest thing in the
programming industry.  It means Rapid Application 
Development, and its missionaries were programming
languages/environments like Visual Basic, PowerBuilder, etc.
Their concern was to be able to quickly produce prototypes
while minimizing the time t in the implementation phase. This
could be important if you're looking to convince your boss
with a new idea.

		Implementation
	      |----------------|
                       t

However, this is only a small piece a program's life-cycle.
The bigger picture, following the Waterfall model, looks
more like

Explore  Requirements  Design  Implementation  Test  Install  Maintain
--------|-------------|-------|---------------|-----|--------|--------|
  .1          .1         .1        .20          .75     .1       .1

Below each stage there is an approximate weight for how much time
is consumed by doing each.  You may agree with experience. So RAD
only looked at a fraction of the real engineering cycle, but
what about the rest?  Usually, the prototype from RAD is 
discarded and a whole new project is started!
  What we want to stress is that maybe the distribution above
need not be the defacto.  What if we spent more time with our
Design & Implementation?  After all, most bugs are results of
poor syntax and notation.

===========================================================
Preventing buggy code
===========================================================
The following are some tips that could help reduce the effort
in debugging your projects.  Realize the trade off, though.
Some of these require more time and attention in coding
than your present methods, if they differ.  But that's the
goal: spend a little more time coding, and a lot less time
debugging!

1.	If you're using a fancy text editor, make use of
	syntax highlighting.  Tokens and some of the colors
	that I use for each are:
	strings:	dark red
	keywords:	blue
	operators:	magenta
	comments:	green
	numbers:	cyan
	background:	light gray (easier on the eyes than off-white)
2.	Comment before you code.  Write your function with
	only comments, each describing what you intend to 
	do.  These prevents you from forgeting details.
	Plus, when you go back to fill in the holes, you'll
	realize that you'll be done sooner than you thought.
3.	Each statement should have AT LEAST a 1 line comment.
	This goes for event the simple ones like:  example++;
	Most cases, the position of an increment like that above
	is very critical to the algorithm's flow, so explain why.
4.	Use longer, more exhaustive variable names than short ones.
	This will help in tracing and understanding what you're
	referencing and why.
5.	Use your text editor's "Smart Indent" option.  In Visual
	Studio, for example, if you select the entire text (Ctrl-A),
	you can have it nicely indented using the shortcut Alt-F8.
6.	Start each new block with '{' on its own line.  This lets
	the reader see where blocks begin, etc.
7.	Leave spaces between operators and their operands.  Too often
	your eyes will overlook something being negated, or
	var=anotherVar will look like var==anotherVar.
8.	Document your pre- and post-conditions above the function.
	This will let you know if some things should or shouldn't be
	null coming in or going out of the function.