1. Introduction to Computers and Programming Style Lecture Professor: Evan Korth New York University

2. Road Map
Style
Principle of proximity
Naming variables
if / else

3. Initialization (revisited)
When you declare a variable, you do not know the value stored in that variable until you place something there. The language specification does not guarantee any initial value.
Until the user initializes the value, the value stored in that memory is called a garbage value.
Java will not allow you to use the garbage value in a calculation or for output. If it is possible that a variable has not been initialized when you try to use it, you will get a compilation error.
So you must initialize the variable before you use it on the right hand side of a calculation or output it to the screen.

4. Principle of Proximity
Advanced tip for initialization
Initialize your variables close to where you use them if possible
Avoid mistakes about value when using late in code (something modified it?)

5. Stay away from variable names ending in a number
Choosing Good Names
Stay away from variable names ending in a number
integer1, month1, etc.
Unclear, and can be confusing when doing mathematical computations (also could be confused with an array)
integer1 = ;
Start out with lower case letter and capitalize first letter of subsequent words
myTotalTaxDue

6. Good Names cont’d Bad variable names Good variable names Y = Y – YY ;
YYY = John + SalesTax ;
Y = Y + LateFee * X1 + XXX ;
Y = Y + sales_tax + late_fee ;
Good variable names
balance = balance – lastPayment ;
monthlyTotal = newPurchases + salesTax ;
balance = balance + lateFee * balance + newCharges ;
balance = balance + newCharges +
salesTax * newCharges ;

7. Should be all caps – underscores can be used to delimit words
CONSTANTS
Should be all caps – underscores can be used to delimit words
E.g. HOUR_DIVISOR

8. The most important naming consideration
The name should fully and accurately describe the entity the variable represents!
Try stating in words what the variable represents
E.g.
bottomTimeWithoutDivePenalty
A good name not easily confused with something else
Easier to remember because it corresponds to subject

9. Avoid cryptic abbreviations and ambiguous names
runningTotal is better than runningTtl
Put modifiers at the end of your variable
expenseAverage not averageExpense
expenseTotal not totalExpense
Keeps more important info first (all related to Expense, no?)
Easier to visualize group and add later
expenseAverage, expenseTotal versus
averageExpense, totalExpense
Later you can add other Expense modifiers and keep them in alphabetical order within Expense “grouping”
expenseAverage, expenseBudget, expenseTotal

10. Some abbreviations are okay (but still unnecessary)
Usually, that is, depending on your environment
avg for average
max for maximum
min for minimum
Fairly clear as to what they stand for, given most people’s general experience
The abbreviation for number is interesting...

11. Num – the exception
The use of num in some cases is an exception to the suggestion of putting modifiers at the end
numStudents is a variable for the total number of students
studentNum is a variable for the number of the current student

12. Count and Index instead
To avoid confusion, may use Count and Index instead
studentCount is a variable for the total number of students
studentIndex is a variable for the number of the current student

13. How long is too long for names?
Studies show programs with identifiers that are on average of 10 to 16 characters long are easier to debug
Programs with names averaging 8 to 20 characters in length are just about as easy to debug

14. Misleading names or abbreviations
Names to avoid
Misleading names or abbreviations
E.g. TRUE would be a bad abbreviation for “Total Returns Under Expectations”
Names with similar meanings
E.g. input and inputVal
Should rename both to avoid confusion and subtle errors
Different meanings but similar names
clientRecs and clientReps
Make them more different, e.g. clientRecords and clientReports

15. Similar sounding names
More Names to avoid
Similar sounding names
wrap, rap
problem when discussing code with others
Misspelled words
Don’t use highlite instead of highlight
Hard to remember HOW it was misspelled
Words that are easy for you or others to misspell
definite, absence, receipt, etc.
Don’t rely on capitalization to distinguish
Input and input, FRD and frd

16. What? Even More Names to avoid?
reserved words (you can’t use these)
int, double, if [etc…]
API names
print, System [etc…]
Names totally unrelated to what variables represent
John, Suzy
Names with hard-to-distinguish characters
head2Toe headZToe
Ttl5 TtlS

17. All this work for names? Why?!
Can actually save you work by reducing the amount of comments necessary
Save you deciphering time (adds up fast!)
Lets you concentrate on problem-solving not problem-creation

18. Pick good spots to break up a long line
Line Continuations
Pick good spots to break up a long line
Break so it’s obvious from reading a line there should be more
E.g.
if ( (totalSaleBeforeTax > 100) &&
(isPreferredCustomer) ) System.out.print("");
Note, the dangling && should alert reader to a break

19. Put a comment after the right brace!
Braces
Whenever adding a left brace to denote a block or method start, add the right brace right away and then fill between them
Put a comment after the right brace!
if ( MyGrade < YourGrade ) { } /* end if (MyGrade < YourGrade) */ else { } /* end else of (MyGrade < YourGrade) */
} /* end program */
Use curly braces even if you only have one statement as the body of a control structure.

20. indentation
Place the brace associated with a control statement (or method / class header) on the next line, indented to the same level as the control statement.
Statements within the braces are indented to the next level.
For example:
public class {
public static void main… … }