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

1. Introduction to Computers and ProgrammingStyle Lecture Professor: Evan KorthNew 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. 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 = 2 + 3 ; • Start out with lower case letter and capitalize first letter of subsequent words myTotalTaxDue

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

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