Upload
jane-prusakova
View
253
Download
0
Tags:
Embed Size (px)
Citation preview
©2010 Improving Enterprises, Inc.
Good CodeWhat, Why, and How to Get There
Austin Java Users 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
©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 value
NOW
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.
It was hard to write
It should be hard to
read
Who is responsible?
©2010 Improving Enterprises, Inc.
Lets make code more…
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 steps
One 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.
“Everything should be made
as simple as possible, but not
simpler.”
– Albert Einstein
©2010 Improving Enterprises, Inc.
Simple vs Fast
Correctness more important than speed
Simple code is more likely to be and stay
correct
Modularize code w/ performance concerns
Optimize locally
©2010 Improving Enterprises, Inc.
Simple vs Flexible
Re-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