1. Code should compile. If it does not compile (DNC), code will be given no credit. And I will not spend long looking for the problem.
2. Code should compile with no warnings or messages.

1. Name your class that has the method "main" in it, with "Client" as part of the class name.
   For homework #1 this isn't hard as I've told you what I want all .java files to be named.
2. For citation, all submitted files, regardless of size, will at the top contain lines which specify
       Programmer, Date, Homework or Laboratory assignment to which it pertains.
3. NOTE, the homework or laboratory number given should match the one used for that particular assignment on the course web pages rather than any private system of your own.
4. If you worked on any code with someone else, either giving or receiving help, you should note that interaction in the head of the relevant code. You should include the name(s) of the person(s) you worked with and what exactly you were consulting on. Failure to do so, will be interpreted very negatively.

   Any submitted code should be fully understood by all parties. Failure to do so will, again, be interpreted very negatively.

5. For citation, all submitted files, regardless of size, will at the top include a brief description of "big picture" workings of your code. Write this to yourself so that if you were to pick up your code six months from now you would be able to quickly modify it or scavenge workable parts of it for another program. You don't want to start from scratch wondering how it does what it does, nor do you want picky implementation details. You want an overview with only enough detail to get you started.

   Example,

                    /*------------------------------------------------------------------ 
   
   Casey Jones
   September 8, 2044
   Homework #1:  Problem 1 - p.45 (1.2.14)
                    Command line arguments are two integers.
   
                    Program makes sure both are positive and prints
                    an informative result about whether or not either
                    evenly divides the other.
   
                    Collaboration: Hunter Smith helped me out on checking for positive numbers.
                                   Showed me how to correctly use variable & convert from args[0].
   
                                   I helped Pat Guntz & Mars Zu with division versus modulus.
                                   They were confused about about how to call from Math.
                                     
   
                    ------------------------------------------------------------------ */
                    

1. Never use any column beyond 80.
   Why? Code which "wraps" is harder to read & understand when viewing (or printing!). Your poor instructor will be doing this A LOT. Column 80 is safe for all reasonably readable font sizes.
2. Do no use tabs.
3. For each "inner" scope, indentation should be exactly 2 spaces.
4. In-line comments must begin in same column and above code they describe.
5. Off-to-side comments must all begin in same column throughout source file.
6. Always leave at least one space between comment delimiter and the comment itself.

   
     //get count of stars from command line         No space between // & g in get
     int cnt = Integer.parseInt( args[0] );
    

7. Make good use of 'white space'.

1. Variable names and method names begin with lowercase letters. Those that read as multiple words are run together, with each successive word capitalized. Examples are circleRadius and upperLeftCorner.
2. Class identifiers begin with uppercase letters. Class names that read as multiple words are run together, with each successive word capitalized. Examples are DinosaurClient and StatsClient. No class should be named with the word 'class' as part of it's name.
3. All variables, method, and function names and identifiers should be carefully named and as meaningful as possible.

1. Every statment must be documented. However, you do not need to give every executable line it's own unique line of documentation. Good documentation requires some thought. It also takes a while to get used to doing it well and often. For some excellent examples of good documentation, look at what your textbook provides. This is the kind of documentation that actually helps you read the source code more easily. It does not repeat the code in English, but rather explains its purpose.

   For example, the below is an excellent example of documentation. One line of documentation explains several statements. And does it well!

       // read three dimensional coordinates from command line
       double x = Double.parseDouble(args[0]);
       double y = Double.parseDouble(args[1]);
       double z = Double.parseDouble(args[2]);
                   

2. Comments should be meaningful. They should explain either what the programmer is doing or why it's being done. They should not simply echo the code as in the following examples.

   Pay attention to what you are doing. It is possible that some sections of your source code are 'self-documenting'. This is likely when you have been thoughtful about your variable names. See below.

   Example - bad because it describes syntax of code:

           int x;                         // declare variables
           int y;                     
           

   Example - bad because it repeats code & adds no extra meaning:

           int r1;                         // three integers 
           int P,t;                     
           

   So what's a good comment for this set of variables?!?
   In this example all variables are so well named, they do not need additional documentation.
   The code is self-documenting.

           double interestRate;
           double amtPrincipal;
           int numYears;
           

1. Boolean statements can & should be used in assignments where appropriate.

   validDayInSept = 1<=day && day<=30; is much better than the following equivalent but awkward code.

   if ( 1<=day && day<=30 ) validDayInSept = true; else validDayInSept = false;

2. Don't use true or false in conditions.

   if ( validDayInSept ) System.out.printf("\n Great Day in Sept" ); is much better than the following equivalent but awkward code.

   if ( validDayInSept == true ) System.out.printf("\n Great Day in Sept" );

   and same for loops

   while ( !done ) { . . . } is much better than the following equivalent but awkward code.

   while ( done == false ) { . . . }

3. Resist the temptation to comment on the language. A comment about a while loop saying that it is a while loop doesn't add any information. However saying that the loop will continue creating smaller inner circles until a minimum radius is reached is VERY HELPFUL. It comments on the problem. Great!
    

   // Make inner circles as long as radius is big enough while (r > 20){ . . . } is much better than the following equivalent but awkward code.

   // while loop for circles while (r > 20){ . . . }

4. Find helpful variable names and set up constant variables with helpful names rather than hard coding values. Compare the two examples below and decide which is more readable. (Hint: I find the first waaaaay superior...)

   while (radius > MINIMUM_RADIUS){ . . . } is much better than the following equivalent but awkward code.

   while (r > 20){ . . . }

Unless assigment specifies otherwise, you must prompt user for input.

1. Give user a very brief idea of what kind of code is running.
       (ie, integer sorting, base conversion, spinning cube, simulation of stock market, etc.)
2. Inform user type of input expected.
3. Inform user of any ranges outside of which input is invalid.
       (ie, maximum's, minimum's, etc.)
4. Inform user of any other hard-coded values or assumptions.
       (ie, If no input entered for point, default is origin (0,0) )

Unless assigment specifies otherwise, you must perform error checking.

How errors are handled, or not, will be assignment dependent. Be sure and check with instructor before submitting for grading/review.

1. No "goto" or equivalent unconditional branching will be allowed in any code submitted for grading which is not using assembly for source. This includes "exit" and "break" statements. The only exception is the "break" statements which are required to properly terminate "switch" cases.