
Ask HN: What books had the greatest effect on how you structure your code? - rufugee
It&#x27;d be interesting to know what books have had the greatest effect on how you structure your code and projects?
======
DanHulton
Code Complete, Steve McConnell.
[http://www.stevemcconnell.com/cc.htm](http://www.stevemcconnell.com/cc.htm)

One of the best books on programming style and function, backed up with actual
research for the recommendations.

~~~
vram22
Same opinion. I always recommend it to my programming students.

Also, The Pragmatic Programmer is good, for topics both about programming and
beyond programming per se.

~~~
akprasad
Ditto for both books, though I prefer _The Effective Engineer_ to _The
Pragmatic Programmer_. I found that quite a bit of the tactical advice in
_TPP_ is already standard practice (e.g. "always use source control").
Comparatively, _TEE_ has more of an emphasis on project planning and
team/company health, and I found that more useful for my work.

~~~
vram22
Thanks for the tip.

------
troels
"Patterns of Enterprise Application Architecture" by Martin Fowler made a big
difference for me at the time. Also, "Domain Driven Design" by Eric Evans.
Both have a focus on high level architecture.

Of books that are more on the craft of programming, "Refactoring" (Also
Fowler) is good. And I enjoyed "Practical Common Lisp" by Peter Seibel too.

In general, I suspect that the value of a book has more to do with where the
reader is, than where the book is.

------
abecedarius
Thinking Forth; Software Tools; SICP; Abstraction and Specification in Program
Development; Essentials of Programming Languages; Paradigms of AI Programming;
I'd like to list something about OO too, but no book I know really measures up
to learning from other programmers. But there's Mark S. Miller's thesis Robust
Composition.

(in roughly chronological order. As you can see from the chronology, it took
me a long time to start to like OOP.)

~~~
mikekchar
Here I was thinking, "I was never really influenced by books. I just read and
wrote a lot of code." But you've reminded me that it's just wrong. Thinking
Forth. Nearly 35 years later it _still_ probably dominates my approach.

Edit: Just realised that it is available under a CC license: [http://thinking-
forth.sourceforge.net/](http://thinking-forth.sourceforge.net/)

~~~
vram22
>Thinking Forth. Nearly 35 years later it still probably dominates my
approach.

That's interesting. Can you elaborate on why you think it dominates your
approach? I'm interested because I had read a good amount of Starting Forth by
Leo Brodie some years ago, and liked the language, and had played around with
it a bit (only got access to a Forth system for a short time, so could not go
deeply into it, on the practical side). But I remember liking the language. I
don't think I have read Thinking Forth.

~~~
abecedarius
For me the biggest influences underemphasized in other sources are to be alert
for relentless simplification, for 'mechanical sympathy', for ways changing
your problem could make it much simpler to solve -- and that there's an
agility in using a simpler programming system like a Forth which you grok and
can change as you need to, which can sometimes outweigh the leverage of a big
one that comes with lots of stuff already done for you. These are useful
points of view even with Forth being almost never the most practical tool now.
Its day was already passing when I learned it in the 80s.

Also, though I don't think this was quite in the book, it helped lead me to
the idea of refactoring and its synergy with automated testing almost a decade
before the idea started spreading.

~~~
mikekchar
Yes, this is pretty much the same as me. The focus of Thinking Forth (as much
as I remember it -- I should re-read it now that I can download it) is about
creating small words that you can compose. The idea was that you could
interactively tests the words as you were writing the code. FORTH is a bit
like Smalltalk in that the environment is always loaded, so you're always
jumping in and out of the editor to try things.

Later when I learned about refactoring and TDD, it felt really natural. Until
now I hadn't made the connection, but it was exactly the same thing I was
doing when I was writing FORTH code.

I also program everything bottom up, rather than top down. I'm pretty sure
this is from the influence Thinking Forth had on me as a programmer. I'll make
a mental sketch of how things will fit together overall, pick a spot, drill
down and then start building the pieces I'm going to need. I refactor as I go.
Finally I plug everything together. This also leads me to do subsystem
decomposition very, very late in the process. Only after I've built the pieces
do I start thinking about where they should ultimately end up. This makes
refactoring a lot easier: first when you are building the pieces because you
don't have to jump through hoops to get at things, and second when you are
assembling because the pieces will naturally fall into places based on what
data they interact with. If you have problems understanding where a piece
should go, then it's a good indication that you have more refactoring to do.

Some people hate the way I do evolutionary design :-) It works for me, though.

~~~
abecedarius
Good points. Another influence I think it had: an attitude like "what one fool
can do, another can". While this doesn't directly affect how you organize
programs, it can arm you against cargo-culting what you read elsewhere. You do
have to watch out for culting up Forth!

------
jjjjjosh
Hands-down, Practical Object-Oriented Design in Ruby
([http://www.poodr.com/](http://www.poodr.com/)) - some of it I don't agree
with but it's all wonderfully put-together: clear and concise, with wonderful
examples. Much more about OO design than Ruby, non-Rubyists will get 98% of
the value out of it that Rubyists would.

~~~
censhin
I'm glad to see someone posted this book. I think it's far undervalued.
Definitely a must read. The Ruby written could be completely replaced by
pseudo code, and it wouldn't change the lessons taught.

------
danso
Of lesser-known books, Avdi Grimm's "Confident Ruby":
[http://www.confidentruby.com/](http://www.confidentruby.com/)

Learning Ruby itself was a huge influence to me; hadn't considered that a
language should be designed to make programmers "happy", as Matz said.
"Confident Ruby" was one of several books that had this human-happiness focus.
"Confident" is broken down into patterns, many of which can be found in books
like Sandi Metz's POODR, but as a semi-experienced programmer, Grimm's way of
writing really appealed to me.

Even the title of the book itself was revelatory to me. The idea that the
functions and methods and conventions we create should be rooted in a
"confident" mentality (such as the old adage of being promiscuous in what a
function accepts, and strict in what it returns) really improved the way I
designed code. Not just in terms of technical proficiency, but with less
cognitive burden, which ultimately leads to the elegant simplicity we desire
in our work.

~~~
artursapek
Ruby makes programmers happy while they're writing their sexy new code base.
It makes them cry when it's time to refactor it.

~~~
caseysoftware
I don't know why you're being voted down.. even Avdi Grimm supports that:

[http://www.virtuouscode.com/2015/08/11/what-its-like-to-
come...](http://www.virtuouscode.com/2015/08/11/what-its-like-to-come-back-to-
a-ruby-project-after-6-months/)

~~~
danso
I didn't downvote but I suspect whoever did saw the GP comment as bashing Ruby
and being off-topic, even though some of my comment talked about Ruby's
philosophy as a whole (though I felt it was important to include the context
in which Grimm's philosophy is grounded).

FWIW, I almost never use Ruby today, having switched to Python for both
teaching and development purposes. That doesn't mean that learning Ruby didn't
influence me. For starters, it taught me the dangers of giving programmers too
much syntactic freedom :).

------
jcmoscon
On LISP, by Paul Graham. LISP was the second language I learned in college,
but only after 6 years programming Java and C# that I came back and really
learned LISP. It was when I realized that I was doing everything wrong. For
example design patterns exists because OO has serious problems that we don't
find in a functional programming language and you only see this when you
understand both paradigms.

~~~
gnaritas
Design patterns exist because common solutions to problems exist, not because
OO has serious problems. I understand both paradigms and Lisp is hardly free
of design patterns. Every time you pass a lambda to a higher order function
you're using a strategy pattern. If you only see design patterns as problems
with OO, you're missing the point of design patterns. All languages have
design patterns. Common design pattern in Lisp, with-X macros to deal with
scoped resource cleanup.

~~~
sideshowb
Are Design Patterns really so out of fashion with the youth of today that
nobody here mentions _Design Patterns_ as their answer?

Because it is mine, for better or worse. It took me from understanding OO to
understanding how to build large systems with OO, writing maintainable code
and using proper encapsulation. A much deeper work than _Code Complete_
(though the latter is worth reading too).

I have used functional languages as well (ML, Lisp; not Haskell yet though I
think I get what monads are; plus I write a lot of Python, C++, JS in
functional style) but I have yet to use them for any project as big. I hope I
get the chance to one day. But for now Design Patterns gets my vote.

~~~
btilly
I'm nearing 50 so I'm hardly a youth.

[http://www.perlmonks.org/?node_id=133399](http://www.perlmonks.org/?node_id=133399)
does a very good job of explaining why _Design Patterns_ is a book to be
careful with. By contrast _Code Complete_ won't steer people wrong.

See [https://steve-yegge.blogspot.com/2006/03/execution-in-
kingdo...](https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html) for a cautionary tale about how a pursuit of OO purity can result
in great verbosity, hiding intent behind a barrage of patterns. Resulting in
code that I, for one, would rather not work with.

~~~
sideshowb
Agree on both those fronts, if you're not careful. Still dp influenced my
coding more than any other book to date, which was the original question.

~~~
btilly
As to that, _Design Patterns_ did not influence my coding style very much. By
contrast _Code Complete_ was the first book that I read about how to structure
code, and I've gained more from it on multiple rereads. I consider it a much
better book.

But then again I'm hardly enthusiastic about OO. See
[http://www.perlmonks.org/?node_id=318257](http://www.perlmonks.org/?node_id=318257)
for more on my perspective.

------
butlersean
Refactoring: Improving the Design of Existing Code

After reading I began to think about programming as an algebraic
transformation from one system to another, in doing so radically reduced the
amount of errors I made.

~~~
keithnz
I got this when it first came out, I was kind of doing it in a "gut feeling"
kind of way, but this made me think of it more as a discipline, and solidified
the idea of micro improvements and let me drop the idea of trying to get it
exactly right the first time.

------
ztjio
It surprised me just how huge the impact was of reading about Flow-based
Programming years ago (J Paul Morrison's book, though, his site is probably a
sufficient substitute
[http://www.jpaulmorrison.com/fbp/](http://www.jpaulmorrison.com/fbp/))

Of course, in recent times, it has become all that much more relevant to me as
I began working in data science/engineering space. Even though it's not
specifically about code structure for a particular language, it addresses a
common flaw in most programming approaches that seem to treat all
functionality as a servant of the current context which is strange and silly
and not how anything works in physical information processing so why do it in
code?

A somewhat common pattern that maps well to FBP is "Railway Oriented
Programming." Though FBP in full takes this well beyond simply shooting errors
along in sideband to the happy path.

------
Jtsummers
_Literate Programming_ , Knuth. My methods have evolved since I first read and
started toying with the ideas here, but this is where it started.

[http://www-cs-faculty.stanford.edu/~uno/lp.html](http://www-cs-
faculty.stanford.edu/~uno/lp.html)

------
beagle3
Essays, not books, but ... everything Ken Iverson wrote:

The Description of Finite Sequential Processes
[http://www.jsoftware.com/papers/DFSP.htm](http://www.jsoftware.com/papers/DFSP.htm)
(see e.g. the concrete implementation of the Simplex algorithm , the hamming
code corrector). It shows that, with the right primitives and notation, a lot
of things are simple and elegant. It's not an necessarily an easy read
(depending on your math level and background), but it is a very rewarding one.

Notation as a tool of thought
[http://www.jsoftware.com/papers/tot.htm](http://www.jsoftware.com/papers/tot.htm)
\- a longer introduction.

Bottom line: a different take on abstraction. It makes a huge difference when
you peel most abstraction layers.

------
oneeyedpigeon
The Art of Unix Programming, Eric S. Raymond.
[http://www.catb.org/esr/writings/taoup/html/](http://www.catb.org/esr/writings/taoup/html/)

I'm still trying to achieve everything he advocates, but what I've managed so
far has been extremely beneficial.

------
InclinedPlane
Refactoring. If I could shove that book down every coder's throat in the world
I would. Or, if I could even just get them to use extract method like ... half
the times they should I'd consider that to be a major historical achievement.

------
MithrilTuxedo
Clean Code by Robert C. Martin

This helped me break my analysis paralysis when it came to figuring out how to
organize my code.

~~~
nip
Excellent recommendation.

The examples are written in Java but it doesn't matter too much as most
concepts covered in the book are language agnostic.

------
davidmoffatt
The Little Lisper by Dan Friedman. It is probably 30 years out of publication
but I pulled it off of my shelf the other day, reread it, and the next day I
noticed that my code had improved. It is a quick read, nothing earth
shattering, but you will be amazed by what you have forgotten.

------
leksak
Game Programming Patterns - without a doubt. Own it in print, but usually only
read it online. To me it's a more exciting read than the GoF book

[http://gameprogrammingpatterns.com/contents.html](http://gameprogrammingpatterns.com/contents.html)

~~~
gauravhp
Thanks for providing online version. Where I am staying I cannot purchase most
of these books mentioned in this thread.

------
dcw303
For C#, Framework Design Guidelines by Cwalina & Abrams. Very clear and
concise pointers for well structured and easy to read code. It's a little out
of date now though, wish they'd update it to a third edition.

~~~
arwhatever
A lot of the design guidelines in that book carry forward many other
technologies. A really great read.

------
d0m
SICP made the biggest difference; it really changed the way I approach
mutability and state management in everything I write (To name just this).

------
oulu2006
The Art of the Metaobject Protocol

[https://mitpress.mit.edu/books/art-metaobject-
protocol](https://mitpress.mit.edu/books/art-metaobject-protocol)

------
Adamantcheese
How To Write Unmaintainable Code by Roedy Green.

The best way to write better code is to avoid writing it badly in the first
place. But you need to know how to write bad code to write code better than
it. Definitely a different way of learning how to write good code, also a good
laugh for anyone in industry.

~~~
teemo91
I am almost tempted to bring it into work and frighten my manager with it :)

------
numbsafari
Writing Basic Adventure Programs for the TRS-80. [1]

It contains this gem [2], which is pretty much how every program works. I
occasionally riff off this diagram for work as an inside joke with myself.

1: [http://www.trs-80.org/writing-basic-adventure-programs-
for-t...](http://www.trs-80.org/writing-basic-adventure-programs-for-the-
trs-80/)

2: [https://imgur.com/gallery/Vz63D](https://imgur.com/gallery/Vz63D)

------
doubleunplussed
Not a book, but the game spacechem [1] made all my code start being more
influenced by the actor model [2] without me really realising it.

[1]
[https://en.wikipedia.org/wiki/SpaceChem](https://en.wikipedia.org/wiki/SpaceChem)

[2]
[https://en.wikipedia.org/wiki/Actor_model](https://en.wikipedia.org/wiki/Actor_model)

------
blain_the_train
For a modern look at systems design i highly recommend "Designing Data-
Intensive Applications (DDIA)" By Martin Kleppmann. Not really about
structuring code, but I think stepping back and realizing your code is part of
a larger system is very illuminating and influence how you write code.

[http://dataintensive.net/](http://dataintensive.net/)

------
fusiongyro
A Mentoring Course in Smalltalk[0]. I was really surprised, after reading and
really loving Design Patterns, that there was still so much to say about OO
design.

I did love Design Patterns a lot though. Purely Functional Data Structures by
Chris Okasaki was also really useful for Haskell, as was Real World Haskell.

Programming Prolog probably had a bigger influence on my Prolog than the other
books, even though I read Art of Prolog and Prolog Programming in Depth first.
Especially the latest edition, it's a really beautiful book.

[0]: [http://www.lulu.com/us/en/shop/andres-valloud/a-mentoring-
co...](http://www.lulu.com/us/en/shop/andres-valloud/a-mentoring-course-on-
smalltalk/paperback/product-3788890.html)

------
e12e
Probably the book that surprised me the most, was "Designing Active Server
Pages" by Scott Mitchell[1] - bought for next to nothing in a sale clearing
out old titles. I don't really program in VBscript or on the .net platform -
but the book demonstrates how much improvement it is possible to get in a
server-side template language (eg: like PHP, ColdFusion) with a bit of
mindfulness to how code is structured.

I'm not sure I would recommend it today, but at the time I read it, in the mid
2000s, it did change my view on these "unmaintainable" technology stacks. I
later came across the fusebox architecture/pattern, originally from ColdFusion
- and realized that many PHP programmers had skipped some history, ending up
reinventing code structure, sometimes badly.

Note that fusebox has grown and changed, I'm mostly talking about the
fundamental ideas, and I don't think the later "port" to using XML was a very
elegant or good idea. For those interested, see:

[https://en.wikipedia.org/wiki/Fusebox_(programming)#Fusebox_...](https://en.wikipedia.org/wiki/Fusebox_\(programming\)#Fusebox_.28version_1.29)
and most of the rest of that page.

[1]
[http://shop.oreilly.com/product/9780596000448.do](http://shop.oreilly.com/product/9780596000448.do)

------
pjc50
Very old, but "C traps and pitfalls":
[http://www.goodreads.com/book/show/706807.C_Traps_and_Pitfal...](http://www.goodreads.com/book/show/706807.C_Traps_and_Pitfalls)

It's essentially a list of anti-patterns to avoid. But crucial to it is the
idea of clarity and avoiding misinterpretation by either human or compiler.

------
skytreader
SICP (w/ Brian Harvey's CS61A lectures) influenced how I approach abstraction
_a lot_. Its "baby brother" _How to Design Programs_, with its design recipe
approach, ingrained testing and iterative refinement in me early on.

_Head First Design Patterns_ is a great influence too when it comes to OO-
abstraction, for good and bad.

~~~
sevensor
I'll second HTDP. A close read of the preface is worth your time even if the
deliberate pace of the rest of the book isn't your cup of tea. The data-first
approach to design is a breath of fresh air.

------
wallstprog
At the risk of being labeled a dinosaur, this is still prob. the best book I
ever read on structuring code:

[https://www.amazon.com/Reliable-Software-Through-
Composite-D...](https://www.amazon.com/Reliable-Software-Through-Composite-
Design/dp/0884052842/ref=asap_bc?ie=UTF8)

------
lj3
Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded
Systems by Miro Samek.

[https://www.amazon.com/Practical-UML-Statecharts-Event-
Drive...](https://www.amazon.com/Practical-UML-Statecharts-Event-Driven-
Programming/dp/0750687061/)

------
cutler
Clojure Applied by Ben Vandergrift and Alex Miller. That and Rich Hickey's
Greatest Hits ([https://changelog.com/posts/rich-hickeys-greatest-
hits](https://changelog.com/posts/rich-hickeys-greatest-hits)).

~~~
zimablue
I haven't read that many coding textbooks not specific to a language but the
Joy of Clojure probably slapped me with the most ideas I'd never seen before.
Not sure it made me a better developer in the short run, but I'd like to think
that it will in the long run.

------
tomjakubowski
"The Practice of Programming" by Kernighan & Pike, especially chapters 3, 4, 8
and 9.

[http://www.cs.princeton.edu/~bwk/tpop.webpage/](http://www.cs.princeton.edu/~bwk/tpop.webpage/)

------
mhh__
Alexandrescu's Modern C++ design taught me how to template properly.

Also, Scott Meyers's books were very helpful.

The design of the D standard library has also been very influential on my code
(Mainly convincing me of the benefits of ranges over iterator)

------
breck
Clean Code

------
ransom1538
Classic essay on unmaintainable-code.

[https://github.com/Droogans/unmaintainable-
code](https://github.com/Droogans/unmaintainable-code)

------
chrismealy
Kent Beck'a Smalltalk book. I've never used Smalltalk but it transfers to any
dynamic OOP language. (It also used to be $25, yikes what happened?)

------
BJanecke
* Douglas Hofstadter - Gödel, Escher, Bach: an Eternal Golden Braid

* Fred Brooks - Design Of Design

* Fred Brooks - The Mythical Man month

* Eric J. Evans - Domain Driven Design

* Design Patterns: Elements of Reusable Object-Oriented Software

* Kent Beck - Extreme Programming Explained

* Kent Beck - Planning Extreme Programming

* Michael C. Feathers - Working Effectively with Legacy Code

* Daniel Kahneman - Thinking, Fast and Slow

[EDIT] Correct the author for legacy code

~~~
vldx
I've just recently bought "Gödel, Escher, Bach" \-- looking shortly to start
it. Curious, how did it influenced you in connection to programming?

~~~
BJanecke
Just like the other non programming book on the list(Thinking Fast and Slow)
GEB is a lot about perception to me.

Understanding that nothing is purely logical nor is it purely expressionistic;
by pigeonholing your perception of any design whether it be Code, Math or Art
to either Logic xor Expression you are blinding yourself

The other angle for GEB is design

I read GEB along with Design of Design years ago following my mentor at the
times suggestion, I would highly recommend doing this. Think of it as the
Gödel, Escher, Bach, Brooks (Although Brook's writing style can be laborious
at times) Recognizing patterns in all design work helped my understand my own
design process better.

~~~
vldx
That's fascinating. Just ordered Design of Design to supplement GEB. Thanks!

------
fernly
Jon Bentley, _Writing Efficient Programs_ and Kernighan & Ritchie's _C
Programming Language_.

------
marvel_boy
Programming using GNU Smalltalk
[http://stephane.ducasse.free.fr/FreeBooks/Gnu/ProgrammingUsi...](http://stephane.ducasse.free.fr/FreeBooks/Gnu/ProgrammingUsingGnuSmalltalk.pdf)

------
CalRobert
Javascript: The Good Parts

------
nichochar
The pragmatic programmer

------
chvid
The Life-Changing Magic of Tidying Up by Marie Kondo

------
anentropic
Does anyone else here never read programming books?

~~~
josmar
They are a great ladder for when one wishes to climb up the shoulders of
giants. Much can be learned in blogs, but long-form text is not that easily
replaced.

That said, my books-to-read list is ever growing as well...

------
nlawalker
_Dependency Injection in .NET_ by Mark Seemann was the trigger that started my
transition from someone basically writing "script spaghetti" in an OO language
to someone that could actually decompose a conceptual set of processes into
decoupled parts and assemble a software system from them.

It came along at just the right moment in my career, when I was struggling to
understand how I could build things in a more elegant way. I picked up the
book thinking I was going to learn about some esoteric design pattern, and
came away with a much better understanding of the languages I was using and
all of the other design patterns I thought I had learned about previously.
It's clear, concise, and focuses on _concepts_ over specific tools and
libraries, but most importantly it's practical - it has real, practical code
examples and explains how to actually build an object-oriented system. It's
such a stark contrast with most presentations I've seen of the Gang of Four
patterns and of SOLID, which usually come with really weak examples that
aren't helpful or motivational.

Everything snowballed from there. I started using composition a lot more than
inheritance, I started identifying problems with side effects and eliminating
them, I started writing real unit tests, I was able to better critique other
peoples' code. I felt like I was finally using the tools available to me in
the way they were supposed to be used.

What's funny and satisfying to me is following the author's blog and seeing
that he has since moved on to focus primarily on F# and functional
programming, which I naturally started to do myself after more practice with
the concepts in his book. Once you start decoupling things well, and you've
built a few systems big enough that you have trouble finding the actual
implementation of your IWhatever and an AbstractSingletonProxyFactoryBean
actually does solve your problem pretty well even as you realize the insanity
of it, the encapsulating borders of classes and the need to assign everything
to a noun start to feel more like a hindrance rather than a guide.

That said, I still think that most of the world's code written in object-
oriented languages would be better off if everyone using them had brief,
practical training to understand the value of specifying the behavior of an
object through the interfaces it depends on, giving it other objects that
implement those interfaces right when you create it, and doing all that
creation up front (or specifying other objects that can defer that creation to
later). I still see so much C# code from developers at all levels who clearly
create classes only because the language offers it and it seems like the right
thing to do, randomly jamming methods and fields into classes with names
vaguely related to the domain, calling static methods to access databases and
external services, and proudly adding unit tests for their one loose little
function that mushes strings together. I push this book as hard as I can on
junior devs.

~~~
harshdeep
+1, This book is real gate opener for my career.

------
rurban
SICP

------
robinphilip1989
Head First Design Patterns by Eric Freeman Design patterns by GoF Code
Complete by Steve McConnel

------
weishigoname
for me, there is no special book effect my code style, the greatest effect is
read source code of projects I am interested in.

------
_Codemonkeyism
"Implementation Patterns"

------
hardlianotion
Scott Meyers Effective C++

------
enriquto
all modern programming books are footnotes to Kernighan and Ritchie

------
ertucetin
Joy Of Clojure

------
PJ_Lau
work effectively with legacy code

------
Kenji
Digital Design and Computer Architecture (Harris & Harris)

Why? Because we software engineers can learn a lot from the hardware guys.
Almost every piece of software I write these days contains some finite state
machines (technically, every program is a finite state machine, where the
binary string that makes up all your variables at a given point in time is one
state, that insight alone is valuable, but I mean with explicit states in the
code) - in fact, they often make up the core structure and uphold some strong
invariants that make reasoning about the code simpler. And if one finite state
machine does not do it, then you can nest them and keep all the benefits.

------
gnaritas
Smalltalk Best Practice Patterns by Kent Beck. Refactoring by Martin Fowler.
Design Patterns by the Gang of Four. Domain Driven Design by Eric Evans.

------
gt_
As a programmer in training who has both Clean Code and Code Complete in a
queue on the edge of my desk, I'm following this thread to decide which goes
first, or if they both get sold in mint condition.

~~~
blub
Code complete is a classic.

Clean code will teach you how writing 3 line functions is a best practice.
It's an overhyped, overrated book which is more damaging than helpful and one
of the very few I couldn't stand to read until the end due to the authors'
dogmatic views.

~~~
Denzel
That's interesting, I had the complete opposite reaction to clean code. As a
person that recommends this book, with full heart, to every developer, I'd
like to hear any details you could spare re: why you believe it's damaging?
Maybe you can provide some examples of well-written codebases and why you
believe they're such? And maybe you could comment on why you feel Clean Code's
principles harm readability with some examples?

I find it painful working with codebases that don't use most of the principles
re:

\- Write code like good stories: Code should read like a story, methodically
descending the call graph method by method; each working at one level of
abstraction.

For example, why is string manipulation littered all over this function that's
supposed to be dealing with consolidating reports? Ugh. I like when one
function stays at one level of abstraction

\- Factor out conditions into descriptive methods: I shouldn't have to sit and
read through 5 logical operators, some arithmetic, and method calls in 1 'if'
conditional, to understand _why_ we're doing all this.

Once again, this goes back to having your code read like a story. Factor it
out into a descriptive function, so that I can understand at a glance and deep
dive if necessary.

\- Comments are a failure: This applies 99.99% of the time. It's almost
comical when someone leaves behind a comment that could be eliminated by
factoring something out into a descriptive method call instead.

There's a lot of other great stuff in Clean Code that I'm forgetting off the
top of my head. (It's been awhile since I last looked over it.)

I've come across very few code bases that are a literal pleasure to read.
[https://github.com/jekyll/jekyll](https://github.com/jekyll/jekyll) is one of
the cleanest codebases that comes to mind immediately. And on the other side
of the coin,
[https://github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)
is one of the dirtiest.

If anyone wants more details/expansion, let me know and I'll reloop. (On my
phone right now.)

~~~
chinhodado
The problem with Clean Code is, just as the post you replied on said, it's
very dogmatic. A problem I often see people who quote Clean Code do is that
they take its principles to the extreme.

An example is tons of tiny methods of 1-3 lines each. Sure splitting up
methods is good practice but it's painful to read code where you continuously
have to "go to definition". There is an article written about this by John
Carmack here [http://number-
none.com/blow/john_carmack_on_inlined_code.htm...](http://number-
none.com/blow/john_carmack_on_inlined_code.html)

Another example is the "comment are a failure" mindset. Sure I don't need
comments that say this code is doing an addition between two numbers, but a
piece of code doing some complex business logic definitely benefits from a
comment explaining what the hell it's doing. No amount of function-splitting
and function-naming can replace such comments. Yet all too often people who
read Clean Code treat comments as some sort of abominations that has to be
avoided at all cost.

~~~
Denzel
A dogmatic book does not make a dogmatic person. And if that's a "problem",
then that's rather a problem with the person reading the book.

Please provide examples of such codebases you're talking about.

One justification of modularity is to hide details. Thus avoiding the need to
"go to definition". If the tests pass and the name is descriptive, then you
should understand the method without needing the details.

For example, Jekyll's Site#process [1] provides a high-level overview of how
the site is built. It reads like simple, plain, easy-to-understand English.
Now, I've chosen to dive into Site#write [2]; it tells me that for each site
file, we're going to write it out to its destination, as long as it's supposed
to be regenerated. Awesome, that's easy to understand.

Say I want to write another method that operates on all the site files. I
don't need to know how Jekyll finds all the site files. Heck, they could be in
specific directories... or it could pull configuration over the network... or
they could be provided through command-line arguments. Who cares! I just use
Site#each_site_file because it's an implementation detail.

And yes, Jekyll provides little 1-3 line helper methods like Site#incremetal?
[3] all over the place to codify conditionals. These are extremely helpful.

On the other side of the coin, do you know what this conditional is for [4] in
Kubernetes? I can't for the life of me understand its purpose without being
_forced_ to look into the details. It'd be much easier to read if it was
extracted out into its own descriptive method such as
_activeMultiNodeInterface_ maybe? I don't know because I literally don't know
the intention of that conditional. The original developer could've made their
intention far more clear to subsequent developers had they extracted it out.

I find your citation of Carmack underwhelming for two reasons: (1) he's
writing to a very specific target audience -- game developers, and (2) he
admits himself, "The whole point of modularity is to hide details, while I am
advocating increased awareness of details." Carmack is in no way supporting
the idea that "it's painful to read code where you continuously have to 'go to
definition'". In fact, quite the opposite, he's advocating a very specific
recommendation to a very specific type of developer working on a very specific
type of project. Simple as that.

You'd do best to provide some examples and empirical data supporting your
assertions.

[1]:
[https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site...](https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site.rb#L69)

[2]:
[https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site...](https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site.rb#L208)

[3]:
[https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site...](https://github.com/jekyll/jekyll/blob/master/lib/jekyll/site.rb#L347)

[4]:
[https://github.com/kubernetes/kubernetes/blob/master/pkg/kub...](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/network/kubenet/kubenet_linux.go#L203)

------
frik
JavaScript, the Good Parts

------
gaius
Alice in Wonderland

------
__s
Fountainhead

------
miguelrochefort
Are _books_ still state of the art in 2017?

I would assume all the best knowledge could be found online for free by now.

~~~
CalRobert
Books are useful for a couple of reasons.

1) It can do wonders for focus to disable your network connection, open a
book, and work through examples (but maybe I just get distracted easily). This
actually applies for most tasks that involve a computer and don't need the
internet.

2) Not specific to print, but a book that covers a topic in a structured,
beginning-to-end way can help reduce gaps in one's knowledge. I learned a bit
of BASH by just googling around and reading Stack Overflow, but reading The
Linux Command Line
([https://www.nostarch.com/tlcl](https://www.nostarch.com/tlcl)) taught me
things I wouldn't have gotten in 10 years of stack overflow browsing.

