Main Microsoft PowerPoint - Minimalism.ppt

Microsoft PowerPoint - Minimalism.ppt

0 / 0
How much do you like this book?
What’s the quality of the file?
Download the book for quality assessment
What’s the quality of the downloaded files?
Language:
english
File:
PDF, 179 KB
Download (pdf, 179 KB)
0 comments
 

You can write a book review and share your experiences. Other readers will always be interested in your opinion of the books you've read. Whether you've loved the book or not, if you give your honest and detailed thoughts then people will find new books that are right for them.
1

Matemática Básica 1

Year:
2006
Language:
spanish
File:
PDF, 15.85 MB
2

The Carrying

Year:
2018
Language:
english
File:
EPUB, 1.35 MB
Minimalism
A Practical Guide to Writing Less Code

Kevlin Henney
kevlin@curbralan.com

Minimalism
It isn't necessary for a work to have a lot of things to look at, to compare, to analyse
one by one, to contemplate. The thing as a whole, its quality as a whole, is what is
interesting. The main things are alone and are more intense, clear and powerful.
Donald Judd

• A movement in art, architecture, music and
interior design
• More generally, a tendency towards less
rather than more
Š Seeking the minimum, the lowest point on a curve

JAOO 2002

http://www.curbralan.com 2

Less Code, More Software
The difference between a good and a poor architect is that the poor architect
succumbs to every temptation and the good one resists it.
Ludwig Wittgenstein

• Creeping featurism and code verbosity do not
add to the used functionality of the software
Š Functionality is weakly correlated with the
number of lines of code written

• On the other hand, minimalism is not the
reduction of source code to line noise
Š Code should be sufficient and fit for purpose
JAOO 2002

http://www.curbralan.com 3

Remove to Improve
The minimum could be defined as the perfection that an artefact achieves when it is
no longer possible to improve it by subtraction. This is the quality that an object
has when every component, every detail, and every junction has been reduced or
condensed to the essentials. It is the result of the omission of the inessentials.
John Pawson

• Yes, it's OK to delete code
Š Controlled and considered code implosion shows
that a project is maturing

• But remember, minimalism is not nihilism
Š Refactoring is a disciplined practice
JAOO 2002

http://www.curbralan.com 4

A Programmer's Dozen
Refactoring, Repairing and Regaining Control
programmer
dozen

a person who writes computer programs.
a group or set of twelve.
The New Oxford Dictionary of English
Asymmetric bounds are most convenient to program in a language like C in which
arrays start from zero: the exclusive upper bound of such an array is equal to the
nu; mber of elements! Thus when we define a C array with 12 elements, 0 is
inclusive lower bound and 12 the exclusive upper bound for the subscripts of the
array.
Andrew Koenig
A baker's dozen contains thirteen items as opposed to the familiar twelve. This
dates from the time when bakers were subject to heavy fines if they served underweight bread. To avoid this danger bakers provided a surplus number of loaves, the
thirteenth loaf in the dozen being called the vantage loaf.
Lock, Stock & Barrel
JAOO 2002

http://www.curbralan.com 5

Recommendation 0
Follow Form
This principle, that of parallel construction, requires that expressions similar in
context and function be outwardly similar. The likeness of form enables the reader
to recognize more readily the likeness of content and function.
Strunk and White

• Suitable idioms in code should be followed to
improve communication
Š Ideolects reduce general comprehensibility

• But idioms should not be followed slavishly if
they make little sense or detract from quality
JAOO 2002

http://www.curbralan.com 6

Recommendation 1
Don't Break Contracts
Politicians are the same everywhere. They promise to build a bridge even when
there's no river.
Nikita Khrushchev

• Methods have a contract for their use
Š Assertions may or may not be enough to enforce
the contract fully

• Subclassing and implemented interfaces
should follow substitutability
Š Unsupported operations or operations that do a
little less or expect a little extra add complexity
JAOO 2002

http://www.curbralan.com 7

Recommendation 2
Include Only What You Need
"I wish you wouldn't keep appearing and vanishing so suddenly: you make one
quite giddy!"
"All right," said the Cat; and this time it vanished quite slowly, beginning with the
end of the tail, and ending with the grin, which remained some time after the rest of
it had gone.
"Well! I've often seen a cat without a grin," thought Alice; "but a grin without a
cat! It's the most curious thing I ever saw in all my life!"
Lewis Carroll

• A class typically defines an interface backed
by an implementation
Š Separate the usage type from the creation type
JAOO 2002

http://www.curbralan.com 8

Recommendation 3
Express Independent Ideas Independently
What do you get when you cross a mosquito with a rock climber?
Nothing, you can't cross a vector and a scalar.

• Normalise dependencies
Š Consolidate common argument lists and decouple
roles within interfaces

• Watch out for porous layers and noosely
coupled code
Š Weak wrapping and cyclic package dependencies
propagate dependencies unnecessarily
JAOO 2002

http://www.curbralan.com 9

Recommendation 4
Parameterize from Above
While moon sets
atop the trees,
leaves cling to rain.
Bashō

• Global packages, Singletons and bundles of
constants should be rationalised or eliminated
Š They introduce coincidental coupling, so code is
less adaptable and harder to test

• Use arguments and interfaces to invert
dependencies
JAOO 2002

http://www.curbralan.com 10

Recommendation 5
Manage Resources Symmetrically
As the sunrise to the night,
As the north wind to the clouds.
Percy Bysshe Shelley

• Garbage collection is insufficient for any
resource other than memory
Š And even then, it can be less than perfect

• Resource management should be explicitly
balanced or fully encapsulated
Š Consider using block objects to wrap resource use
JAOO 2002

http://www.curbralan.com 11

Recommendation 6
Encapsulate
encapsulate enclose (something) in or as if in a capsule.
ƒ express the essential feature of (someone or something) succinctly.
ƒ enclose (a message or signal) in a set of codes which allow use by or transfer
through different computer systems or networks.
ƒ provide an interface for (a piece of software or hardware) to allow or
simplify access for the user.
The New Oxford Dictionary of English

• Encapsulation is more than just data hiding
Š Self-containedness includes exception safety,
thread safety, ease of use, transparency, etc.

• Encapsulation reduces affordances
JAOO 2002

http://www.curbralan.com 12

Recommendation 7
Flow Don't Jump
Still glides the Stream, and shall for ever glide;
The Form remains, the Function never dies.
William Wordsworth

• Jumpy control flow should be used sparingly
Š It is easy to get addicted to break and early returns
— and continue and goto (where it exists)
Š throw is an exception

• Control flow that doesn't flow can be hard to
comprehend and refactor
Š Structured programming is not completely dead
JAOO 2002

http://www.curbralan.com 13

Recommendation 8
Sharpen Fuzzy Logic
This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man.
William Shakespeare

• Many verbose coding practices are justified
because they simplify debugging
Š This is solving the wrong problem

• Boolean algebra is not rocket science
Š Although you may use it for that purpose

JAOO 2002

http://www.curbralan.com 14

Recommendation 9
Hand Redundant Code its Notice
Omit needless words.
Strunk and White

• Code may be less than the sum of its parts
Š Redundant code is code that has no genuine effect

• Redundant code acts as a speed bump to
understanding — remove it
Š Unreachable code, synchronising non-thread
affected code, unused code, etc.

JAOO 2002

http://www.curbralan.com 15

Recommendation 10
Let the Code Make the Decisions
His had been an intellectual decision founded on his conviction that if a little
knowledge was a dangerous thing, a lot was lethal.
Tom Sharpe

• There is no need to spell everything out in
minute detail
Š Control flow becomes a patchwork of special cases

• Code can also appear to do more than the sum
of its parts
Š Polymorphism, lookup tables, grouped actions on
collections, double dispatch, etc.
JAOO 2002

http://www.curbralan.com 16

Recommendation 11
Consider Duplicate Code to be a Mistake
You cannot step twice into the same river.
Heraclitus

• A lot of programs suffer from a persistent case
of the common code
Š Duplicate code is long grass in which bugs thrive

• Visible duplication is a problem best solved
by refactoring the commonality
Š Into a class, a method or a block surrounded by
clearer logic
JAOO 2002

http://www.curbralan.com 17

Recommendation 12
Prefer Code to Comments
1.
2.
3.

4.
5.

If a program is incorrect, it matters little what the documentation says.
If documentation does not agree with the code, it is not worth much.
Consequently, code must largely document itself. If it cannot, rewrite the code
rather than increase the supplementary documentation. Good code needs fewer
comments than bad code does.
Comments should provide additional information that is not readily obtainable
from the code itself. They should never parrot the code.
Mnemonic variable names and labels, and a layout that emphasizes logical
structure, help make a program self-documenting.
Kernighan and Plauger

• Code that is not code needs a clear role
Š Most comments do not qualify
JAOO 2002

http://www.curbralan.com 18

Summary
Remember that there is no code faster than no code.
Taligent's Guide to Designing Programs

• Baroquecratic practices and just-in-case code
have a br(e)aking effect
Š The measure of code is in software behaviour

• Developmental requirements are as important
as functional and operational requirements
Š Attention to developmental requirements makes
other requirements easier to address
JAOO 2002

http://www.curbralan.com 19