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

Road Map Style –Principle of proximity –Naming variables –if / else

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.

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?)

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 words myTotalTaxDue

Good Names cont’d Bad 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 ;

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

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

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

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...

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

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

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

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

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

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

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

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

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… … }