Documentation and Style Documentation and Comments o Programs

  • Slides: 6
Download presentation
Documentation and Style

Documentation and Style

Documentation and Comments o Programs should be self-documenting. o Use meaningful variable names. o

Documentation and Comments o Programs should be self-documenting. o Use meaningful variable names. o Use indentation and white space to show program structure (j. GRASP does most of this automatically) o Use comments to explain what the program is doing.

Comments in Java o Anything following a double slash (//) on a line is

Comments in Java o Anything following a double slash (//) on a line is considered a comment, e. g. , double radius; //in inches q Anything between the symbols /* and */, no matter how many lines are included, is considered to be a comment, e. g. , /* This is a comment */

Program Comment Header o It’s good to put a comment header block at the

Program Comment Header o It’s good to put a comment header block at the beginning of each separately compilable piece of code. For example, for this class you might have a header like the following: /* Purpose: to determine the area of a circle Author: Jane Q. Programmer E-mail Address: jqprogrammer@csun. edu Programming Assignment: #3 Last Changed: September 1, 2009 */

Placement of Brackets and Indentation o One convention for the placement of brackets is

Placement of Brackets and Indentation o One convention for the placement of brackets is the one used in our textbook (example). o A second convention is to line up the open and close brackets in the same column (example). o The code inside each set of brackets is indented.

Naming Constants o Place the keywords public static final in front of the declaration

Naming Constants o Place the keywords public static final in front of the declaration setting the value of the constant, e. g. , public static final double PI = 3. 14159; q By convention constants are named using all capital letters.