1 / 14

Principles of Design

Principles of Design. Basics - Formatting. Indent nested code Break up long lines Use meaningful names Don’t abbreviate Don’t use names that differ only in case Document consistently and keep it up to date Document preconditions, postconditions, and invariants. Basics - Naming.

ishi
Download Presentation

Principles of Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Principles of Design

  2. Basics - Formatting • Indent nested code • Break up long lines • Use meaningful names • Don’t abbreviate • Don’t use names that differ only in case • Document consistently and keep it up to date • Document preconditions, postconditions, and invariants

  3. Basics - Naming • Package names • Lower case • Reverse company’s internet domain • Class names • Start with uppercase, then upper for each additional word in the name • Use nouns as names • Interface names • Use nouns or adjectives • Same capitalization as classes

  4. More on Naming • Methods • Start with lowercase and then capitalize additional words in the name • Names should be verbs • Use “get”, “set”, and “is” for accessor methods • Variables • Same capitalization as methods • Should be nouns, plural when necessary • Establish and stick to clip names for throwaway variables (g) • Constants • ALL_CAPS with underscore between additional words

  5. Bad Smells in Code (Fowler, Beck) • Refactor: changing existing code to have better design without changing its functionality • How do you know when code needs refactoring? Bad smells!

  6. Stink: Duplicated Code • Don’t copy and paste! • Put repeated code into a method. If the repeated code is in more than one object, put the code in the superclass of the two objects, or create an interface.

  7. Stink: Long method • Long methods are harder to understand and harder to maintain • Put long conditionals in separate methods • Comment often, but better… • Have self-commenting code

  8. Stink: Large Class • Too many instance variables leads to repeated code • Bundle instances together in objects

  9. Stink: Long parameter list • Instead of passing small data, pass the object that holds several pieces of data you will need.

  10. Stink: Shotgun Surgery • To make a change to the code, I have to change lots of little pieces of a lot of classes. • Foresee changes, put the parts that will need to be modified in one place.

  11. Stink: Feature Envy • Method in one class is more interested in another class than the one it currently resides in • Takes an object parameter and does a lot of “gets” to do its job • Put the method in the other class

  12. Stink: Data clumps • Places where pieces of data “hang out together” • Don’t see one without the others • Make a class!

  13. Stink: Switch statements • Usually is a place where polymorphism should occur • Usually switch statements are copied

  14. Stink (my pet peeve!): Intentionally misleading code • Don’t use ints when you mean booleans • Use break and continue sparingly • Name variables nouns, methods verbs • Make your code as readable as possible

More Related