Algorithm Programming Coding Advices Bar-Ilan University תשס " ו by Moshe Fresko

Programming Principles A Good Program must have following traits. Readability Program will be read, by other people or even in the future by us Maintainability The problem for which the program was originally written may evolve and change over time. Reliability To assure not to introduce errors into programs. Performance Programs must perform well enough to do the task. Effectiveness Not to waste resources. In programming task to take care of the following Planning : Thinking about the programming task as a whole. Stylistic patterns : Program must look nice and readible. Design and Structuring How to structure your code to aid maintainability and safety. Safety To prevent errors.

Programming practice Starting Pair Programming (Maintainability) Better to work in pairs. Two minds are better than one. Scheduling a Task (Planning) Timing a schedule can be learned by practice. Try to estimate every task you have and learn from previous estimation inaccuracy. It is easier to estimate small tasks. So divide the task. Piecemeal Growth (Planning) Hard to write large programs in one shot. So write a working small program, and then expand it.

Programming practice Designing One Service Per Class (Structural) A program is easier to maintain when it is made up of small simple parts, so give each class one job to do. Polymorphism before Selection (Structural) Good OO programs use relatively few if-switch statements. Most decisions must be made via the polymorphism. Logical Interfaces (Maintainability) The interface should define logical services, rather then its implementation. Complete Interfaces (Design) Provide a set of public methods in your class that permits the client software to perform all legal transformations. Make sure that clients will have access to all needed aspects of this service. Example: A Stack implementation needs isEmpty() method Stack must make possible for the client to decide the response to an error Strong encapsulation (Safety) Don ’ t reveal the details of your implementation, even indirectly. Example: Don ’ t return an internal Container, unless it is immutable To return Iterator is a poor practice, especially if it has a Remove or Modify method.

Programming practice Getting Ready to Program Rewrite (Planning) Rewrite your program several times. Rewrite it at least once before you show it to anyone. Optimize for Readability (Maintainability) Make your code as clear and correct as possible, not as fast as possible. Intention Revealing Name (Maintainability) All the names in your programs (variables, parameters, classes, methods) should denote the purpose of the item they refer to.. Consistent Naming (Maintainability) Use a consistent style for naming things in your program. Public Features First (Stylistic) List the public parts of your class first, and the private parts last. Private Fields (Safety) All of your fields should be private. Provide protected accessor functions when necessary. Initialize (Safety) When you declare a field or local variable, initialize it immediately.

Programming practice Getting Ready to Program Test Everything Now (Safety) When you write any code, write a test for it as well. Assign Variables Once (Design) Once you have given a variable a value, do not change it if at all possible. The value should preferably assigned when the variable is declared. If possible make them final. Short Method (Structural) Your methods should usually be short. Break up long or complicated methods into parts. Write Method Objects when needed Comment (only) when necessary (Maintainability) Make your comments to indicate the intent of the program. i++ ; // increment i => a worthless comment i++ ; // increment the card counter => a better comment cardCounter++ ; => no comment needed Say it once (Structural) Make little pieces. Don ’ t write similar codes several times.

Programming practice Coding Indent for Structure (Stylistic) The parts of a structure should be indented from the keywords and punctuation symbols. All of the statements at the same level of the structure should be indented exactly the same amount. Don ’ t indent too much or too little. Brace All (Stylistic) Completely brace all statement parts in all structures even if it has a single expression. Braces Line Up (Structural) When writing brace symbols, if the opening and closing symbol don ’ t both fit on the same line, then make them line up exactly vertically. Use Spaces instead of Tabs (Maintainability) Some editors put spaces when pressing to Tab Consistent Capitalization (Stylistic) Capitalize consistently to show the kind of thing a name refers to. Capitalize the first letter of : Class Name, Interface Name. Never capitalize the first letter of a method name or variable name. Constant names are completely capitalized Package names are all small letters. For a name having a couple of words, capitalize the words except the first one

Programming practice Coding (Cont.) Name Your Constants (Maintainability) Name any important constant values in your program and refer to them only by name. Spell it out (Maintainability) Don ’ t abbreviate your method and variable names. Locals When Needed (Design) Use local variables when they are used to avoid duplicate computation, and otherwise avoid their use when the intent is clear without them. One statement per line (Stylistic) Write your programs so that there is only one statement on each line. Short lines (Maintainability) Keep your lines short so that it can be grasped on the screen and on the printer. Function instead of a Complex Condition Any complex condition should be written as a separate method. Use “ this. ” (Maintainability) When you refer to a field of the current object, prefix the reference with “ this. ” Local Variables Reassigned Above Their Use