Clean Code Software Engineering

Software Engineering Reading
Group: Clean Code
Chapter 1
Led by Nicholas Vaidyanathan
http://www.nicholasvaidyanathan.info
Lead Visionary, Visionary Software Solutions
http://www.visionarysoftwaresolutions.com

Foreword
 Writing clean code is what you must
do in order to call yourself a
professional.
 There is no reasonable excuse for
doing anything less than your best.

Philosophy
 “Honesty in small things is not a small thing.”
 The late-1990s notions of design driven only by
the tests and the code are long gone. Yet
attentiveness to detail is an even more critical
foundation of professionalism than is any grand
vision.
1. It is through practice in the small that
professionals gain proficiency and trust for
practice in the large.
2. The smallest bit of sloppy construction, of the
door that does not close tightly or the slightly
crooked tile on the floor, or even the messy
desk, completely dispels the charm of the
larger whole. That is what clean code is about.

The importance of Maintenance
 In software, 80% or more of what we
do is quaintly called “maintenance”:
the act of repair.
 Rather than embracing the typical
Western focus on producing good
software, we should be thinking more
like home repairmen in the building
industry, or auto mechanics in the
automotive field.

5S – Total Productive
Maintenance
1. Seiri, or organization (think “sort” in English). Knowing
where things are—using approaches such as suitable
naming—is crucial.
2. Seiton, or tidiness (think “systematize” in English). A place
for everything, and everything in its place. A piece of code
should be where you expect to find it—and, if not, you
should re-factor to get it there.
3. Seiso, or cleaning (think “shine” in English): What do the
authors here say about littering your code with comments
and commented-out code lines that capture history or
wishes for the future? Get rid of them.
4. Seiketsu, or standardization: Do you think this book says
anything about having a consistent coding style and set of
5. practices within the group?
6. Shutsuke, or discipline (self-discipline). This means
having the discipline to follow the practices and to
frequently reflect on one’s work and be willing to change.

How to maintain optimally
 In code, refactor mercilessly.
 Making your code readable is as
important as making it executable.
 As Fred Brooks admonishes us, we
should probably re-do major software
chunks from scratch every seven years
or so to sweep away creeping cruft.
 You should name a variable using the
same care with which you name a first-
born child.

The importance of care
 “Back in my days working in the Bell Labs Software
Production Research organization (Production, indeed!) we
had some back-of-the-envelope findings that suggested that
consistent indentation style was one of the most statistically
significant indicators of low bug density.”
 “We want it to be that architecture or programming language
or some other high notion should be the cause of quality; as
people whose supposed professionalism owes to the mastery
of tools and lofty design methods, we feel insulted by the
value that those factory floor machines, the coders, add
through the simple consistent application of an indentation
style.”
 “Quality is the result of a million selfless acts of care—not just
of any great method that descends from the heavens.”

The beauty of refinement
 “while rework in the manufacturing metaphor leads to
cost, rework in design leads to value. We should view
our code as the beautiful articulation of noble efforts of
design—design as a process, not a static endpoint. It’s
in the code that the architectural metrics of coupling and
cohesion play out.”
 “Neither architecture nor clean code insist on perfection,
only on honesty and doing the best we can. To err is
human; to forgive, divine.”
 “In Scrum, we make everything visible. We air our dirty
laundry. We are honest about the state of our code
because code is never perfect. We become more fully
human, more worthy of the divine, and closer
 to that greatness in the details.”

Introduction
 “There are two parts to learning craftsmanship:
knowledge and work. You must gain
1. the knowledge of principles, patterns, practices, and
heuristics that a craftsman knows
2. you must also grind that knowledge into your fingers,
eyes, and gut by working hard and practicing.
 “Learning to write clean code is hard work. It requires
more than just the knowledge of principles and patterns.
You must sweat over it. You must practice it yourself,
and watch yourself fail. You must watch others practice
it and fail. You must see them stumble and retrace their
steps. You must see them agonize over decisions and
see the price they pay for making those decisions the
wrong way.”

Book sections
1. The first several chapters describe the principles,
patterns, and practices of writing clean code. There is
quite a bit of code in these chapters, and they will be
challenging to read. They’ll prepare you for the
second section to come.
2. The second part of the book is the harder work. It
consists of several case studies of ever-increasing
complexity. Each case study is an exercise in cleaning
up some code—of transforming code that has some
problems into code that has fewer problems. The
detail in this section is intense.
3. The third part of this book is the payoff. It is a single
chapter containing a list of heuristics and smells
gathered while creating the case studies.

Let there be Code…and it was
good!
 “One might argue that a book about code is
somehow behind the times—that code is no
longer the issue; that we should be
concerned about models and requirements
instead. Indeed some have suggested that
we are close to the end of code.”
 “Nonsense! We will never be rid of code,
because code represents the details of the
requirements. At some level those details
cannot be ignored or abstracted; they have to
be specified. And specifying requirements in
such detail that a machine can execute them
is programming. Such a specification is
code.”

Bad code is bad, mmmkay?
 “I know of one company that, in the late 80s,
wrote a killer app. It was very popular, and
lots of professionals bought and used it. But
then the release cycles began to
stretch…The company went out of
business…Two decades later I met one of
the early employees of that company and
asked him what had happened…They had
rushed the product to market and had made
a huge mess in the code. As they added
more and more features, the code got worse
and worse until they simply could not manage
it any longer. It was the bad code that brought
the company down.”

Reasons for bad code
1. Were you trying to go fast? Were you in a rush?
Probably so.
2. Perhaps you felt that you didn’t have time to do
a good job; that your boss would be angry with
you if you took the time to clean up your code.
3. Perhaps you were just tired of working on this
program and wanted it to be over.
4. Maybe you looked at the backlog of other stuff
that you had promised to get done and realized
that you needed to slam this module together
so you could move on to the next.
 We’ve all done it.
 http://codeoffsets.com/

But just who’s fault is it?
 Why does good code rot so quickly into
bad code?
◦ We complain that the requirements changed
in ways that thwart the original design.
◦ We bemoan the schedules that were too tight
to do things right.
◦ We blather about stupid managers and
intolerant customers and useless marketing
types and telephone sanitizers.
 But the fault, dear Dilbert, is not in our
stars, but in ourselves.
 We are unprofessional.

Really? But what about THEM!?!
 The managers and marketers look to us for
the information they need to make promises
and commitments; and even when they don’t
look to us, we should not be shy about telling
them what we think.
 The users look to us to validate the way the
requirements will fit into the system.
 The project managers look to us to help work
out the schedule.
 We are deeply complicit in the planning of the
project and share a great deal of the
responsibility for any failures; especially if
those failures have to do with bad code!

But…
 “But wait!” you say. “If I don’t do what my
manager says, I’ll be fired.” Probably not.
Most managers want the truth, even when
they don’t act like it. Most managers want
good code, even when they are obsessing
about the schedule. They may defend the
schedule and requirements with passion; but
that’s their job. It’s your job to defend the
code with equal passion.”
 it is unprofessional for programmers to
bend to the will of managers who don’t
understand the risks of making messes.

So what is Clean Code?
 Stoustrup – Inventor of C++
◦ I like my code to be elegant and efficient.
The logic should be straightforward to
make it hard for bugs to hide, the
dependencies minimal to ease
maintenance, error handling complete
according to an articulated strategy, and
performance close to optimal so as not to
tempt people to make the code messy
with unprincipled optimizations. Clean
code does one thing well.

Parsing the description
 Elegant = Pleasing
◦ “Apparently Bjarne thinks that clean code is
pleasing to read. Reading it should make you
smile the way a well-crafted music box or
well-designed car would.”
 Efficient = Pure
◦ “note the word that Bjarne uses to describe
the consequence of that inelegance. He uses
the word “tempt.” There is a deep truth here.
Bad code tempts the mess to grow! When
others change bad code, they tend to make it
worse.”
 Don’t Live With Broken Windows!

Error Handling is Attention to
detail
 “Bjarne also mentions that error handing
should be complete. This goes to the
discipline of paying attention to details.
Abbreviated error handling is just one
way that programmers gloss over details.
Memory leaks are another, race
conditions still another. Inconsistent
naming yet another. The upshot is that
clean code exhibits close attention to
detail.”

Doing One thing well is Focus
 “Bjarne closes with the assertion that
clean code does one thing well. It is no
accident that there are so many
principles of software design that can be
boiled down to this simple admonition.”
 “Bad code tries to do too much, it has
muddled intent and ambiguity of
purpose. Clean code is focused. Each
function, each class, each module
exposes a single-minded attitude that
remains entirely undistracted, and
unpolluted, by the surrounding details.”

 Booch – OOP Architectural expert
◦ Clean code is simple and direct. Clean
code reads like well-written prose. Clean
code never obscures the designer’s intent
but rather is full of crisp abstractions and
straightforward lines of control.

 Grady makes some of the same points as
Bjarne, but he takes a readability perspective.
 Like a good novel, clean code should clearly
expose the tensions in the problem to be
solved. It should build those tensions to a
climax and then give the reader that “Aha! Of
course!” as the issues and tensions are
resolved in the revelation of an obvious
solution.”
 “Our code should be matter-of-fact as
opposed to speculative. It should contain only
what is necessary. Our readers should
perceive us to have been decisive.”

 Thomas – Founder of Object Technology
Initiative and godfather of Eclipse
◦ Clean code can be read, and enhanced by a
developer other than its original author. It has
unit and acceptance tests. It has meaningful
names. It provides one way rather than many
ways for doing one thing. It has minimal
dependencies, which are explicitly defined,
and provides a clear and minimal API. Code
should be literate since depending on the
language, not all necessary information can
be expressed clearly in code alone.

 “Big Dave shares Grady’s desire for
readability, but with an important twist. Dave
asserts that clean code makes it easy for
other people to enhance it.”
 “Code, without tests, is not clean. No matter
how elegant it is, no matter how readable and
accessible, if it hath not tests, it be unclean.”
 “Dave uses the word minimal twice.
Apparently he values code that is small,
rather than code that is large. Indeed, this
has been a common refrain throughout
software literature since its inception. Smaller
is better.”

 Feathers – author of Working Effectively
with Legacy Code
◦ I could list all of the qualities that I notice in
clean code, but there is one overarching
quality that leads to all of them. Clean code
always looks like it was written by someone
who cares. There is nothing obvious that you
can do to make it better. All of those things
were thought about by the code’s author, and
if you try to imagine improvements, you’re led
back to where you are, sitting in appreciation
of the code someone left for you—code left
by someone who cares deeply about the
craft.

Parsing the Description
 Sharing is caring!
 Simple and orderly shows great care
 Attention to detail shows care

◦ In recent years I begin, and nearly end,
with Beck’s rules of simple code. In
priority order, simple code:
◦ • Runs all the tests;
◦ • Contains no duplication;
◦ • Expresses all the design ideas that are
in the system;
◦ • Minimizes the number of entities such as
classes, methods, functions, and the like.

 “No duplication, one thing,
expressiveness, tiny abstractions.
Everything is there.”

 Cunningham – SW Engineering God
◦ You know you are working on clean code
when each routine you read turns out to
be pretty much what you expected. You
can call it beautiful code when the code
also makes it look like the language was
made for the problem.

Parsing the Description
 “Ward expects that when you read clean
code you won’t be surprised at all. Indeed,
you won’t even expend much effort. You will
read it, and it will be pretty much what you
expected. It will be obvious, simple, and
compelling.”
 “He says that beautiful code makes the
language look like it was made for the
problem! So it’s our responsibility to make the
language look simple…It is not the language
that makes programs appear simple. It is the
programmer that make the language appear
simple!”

Clean Code, Uncle Bob’s Way
 “We will tell you what we think makes a clean
variable name, a clean function, a clean
class, etc. We will present these opinions as
absolutes, and we will not apologize for our
stridence. To us, at this point in our careers,
they are absolutes. They are our school of
thought about clean code.”
 “None of these different schools is absolutely
right. Yet within a particular school we act as
though the teachings and techniques are
right. After all, there is a right way to practice
Hakkoryu Jiu Jitsu, or Jeet Kune Do. But this
rightness within a school does not invalidate
the teachings of a different school.”

We Are Authors
 A majority of our time is spent reading
code, not actually writing it!
 “Indeed, the ratio of time spent
reading vs. writing is well over 10:1.
We are constantly reading old code as
part of the effort to write new code”
 Making it easy to read actually makes
it easier to write

The Boy Scout Rule
 “It’s not enough to write the code well.
The code has to be kept clean over
time. We’ve all seen code rot and
degrade as time passes.”
 “Leave the campground cleaner than
you found it.”

Clean Code Software Engineering

Recommended

More Related Content

Similar to Clean Code Software Engineering (20)

More from Inocentshuja Ahmad (20)

Recently uploaded (20)

Clean Code Software Engineering