©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.

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 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.

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

©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.

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 speed

Simple code is more likely to be and stay

correct

Modularize code w/ performance concerns

Optimize locally

©2010 Improving Enterprises, Inc.

©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

©2010 Improving Enterprises, Inc.

Good CodeWhat, Why, and How to Get There

https://github.com/joshrizzo/ReadabilityJava/

Austin Java Users Group 2015

Jane Prusakova

Josh Rizzo

@Improving Enterprises College Station