©2010 Improving Enterprises, Inc.
Good CodeWhat, Why, and How to Get There
Houston Java Group 2015
Jane Prusakova
Josh Rizzo
@Improving Enterprises College Station
©2010 Improving Enterprises, Inc.
What is “good”?
Functional
Bug-free
Performant
Good design
Tested
Testable
Easy to change
READABLE
©2010 Improving Enterprises, Inc.
Usability
Users and clients Developers
©2010 Improving Enterprises, Inc.
©2010 Improving Enterprises, Inc.
“Programs must be written for people to read, and only incidentally for machines to execute.”
– Abelson and Sussman
©2010 Improving Enterprises, Inc.
Readability has valueNOW
Code is an asset
affects productivity
monetary value
Readability has value OVER TIME
Software evolves over time
Work by many different teams
Changes affect value
©2010 Improving Enterprises, Inc.
Readability has cost
More hard work
More time
More training
©2010 Improving Enterprises, Inc.
How good code does not happen
©2010 Improving Enterprises, Inc.
Readable code
Easy to read
Has a narrative
UnambiguousWYSIWYG
Follows convention
©2010 Improving Enterprises, Inc.
It was hard to write
It should be hard to read
Who is responsible?
©2010 Improving Enterprises, Inc.
Lets make code more…
READABLE
See: https://github.com/joshrizzo/ReadabilityJava
©2010 Improving Enterprises, Inc.
Visible code
White space!
Spacing and indent matter
The Law of Demeter
– avoid the “train wreck” coding style
Step 1
©2010 Improving Enterprises, Inc.
Small stepsOne thing at a time
Glance-sized chunks
“Programming can be fun, so can cryptography; however they should not be combined.”
– Kreitzberg and Shneiderman
Step 2
©2010 Improving Enterprises, Inc.
Code with a narrativeUse naming to show intent
Testable code
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
– Brian W. Kernighan
Step 3
©2010 Improving Enterprises, Inc.
Single Responsibility
Architecture
Interface design
"Good design adds value faster than it adds cost."
- Thomas C. Gale
Step 4
©2010 Improving Enterprises, Inc.
Easy to read
Single level of abstraction
“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.”
– Edsger Dijkstra
Step 5
©2010 Improving Enterprises, Inc.
Readable++Simplicity
©2010 Improving Enterprises, Inc.
“Everything should be made as simple as possible, but not simpler.”
– Albert Einstein
©2010 Improving Enterprises, Inc.
Simple vs Fast
Correctness more important than speedSimple code is more likely to be and stay correct
Modularize code w/ performance concernsOptimize locally
©2010 Improving Enterprises, Inc.
©2010 Improving Enterprises, Inc.
Simple vs FlexibleRe-use is rare
Predictions of re-use are poor
Raises complexity significantly
Unused => not working
©2010 Improving Enterprises, Inc.
Simple vs Clever
Over engineering
Mixing abstractions
Inappropriate patterns
Complicated syntax
©2010 Improving Enterprises, Inc.
Good CodeWhat, Why, and How to Get There
https://github.com/joshrizzo/ReadabilityJava/
Houston Java Group 2015
Jane Prusakova
Josh Rizzo
@Improving Enterprises College Station