Program Style Chapter 22 IB103 Week 12 (part 2)

Modularity: the ability to reuse code Encapsulation: hide data access directly but may use methods (the outside world does not “see” data) Names: use good self documenting names for variables, methods, classes, packages Indentation not required but help readability – also emphasizes structure, not magic can lead to false assumptions (use care and be consistent)

Program Style continued Blank lines – separate methods improve readability New pages (maybe each new class) Optional Comments // /* … */ /** … */ used for documentation JDK

More Style continued Constants Final pi = ; Star = “*”; only have to change one line in program in constant ever changes Method Size no rule but convention about 40 lines (seat of pants rule too long if you start squirming in your seat after trying to follow logic of method)

Classes : one to two pages (no rule convention) Methods: names self documenting Field order: variables public then private Consistency Be consistent (See James Gosling’s libraries) Nested ifs – avoid if complex and difficult to follow logic Nested loops – keep simple, keep logic clear to reader – just because a program runs does not make it good but if it is easy to follow it probably is a good program (or can be easily fixed)

Complexity: better to simplify so readers can understand Documentation: Program specifications Source code – with comments Design information (hierarchy diagrams) Test schedule – results if available Modification history User manual