
Is Clean Code Necessary? - coderjean1
https://jeanrenesite.wordpress.com/2016/06/15/is-clean-code-necessary-part-i/
======
stupidcar
Personally, I've found that heavy application of OO patterns leads to code
that is very unclean, in terms of being "simple and direct".

First developers apply the single-responsibility principle, and break down
previously large but comprehendible classes in thousands of tiny components.
While each component is trivial on its own, the truth of how they combine to
produce a particular application feature is now hidden within an implicit
object graph that cannot be understood by new developers, except through a
torturous process of cross-checking and debugging until they have built a
fragile mental model of what's going on.

Next developers get embarrassed by all the new-ing up of components they're
doing, so they introduce dependency injection. But rather than just injecting
those things that have a genuine need for varying implementations, suddenly
everything gets to be a service. Abstractions proliferate, factory factories
appear, everything is behind an interface (with a single "default"
implementation), and navigating the codebase becomes a nightmare.

~~~
noir_lord
Not convinced it's the application of OO patterns that leads to bad code but
bad programmers (at least in the major part).

I've seen clean code bases in OO/functional and pure procedural and bad code
bases in those as well.

I think it's tempting to blame bad code on things like bad languages and bad
architectural patterns because they are externalities and can be blamed
without mentioning the gorilla in the room, bad programmers write bad code.

I'm not clever so I don't write 'clever' code, I actually find it hard to work
on code bases where they tried to be clever or do too much in one
function/class.

Architecture is like salt, a little enhances, a lot ruins.

I don't write simple clear code out of any sense of purity or attempt to be
'clean' but because I know that in six months when I open this file it'll be
me fixing it and I won't understand what the hell $me-6mths was thinking.

~~~
FranOntanaya
> Not convinced it's the application of OO patterns that leads to bad code but
> bad programmers

There's one thing I would point at. When non OO code is bad you can usually
point at the problem: bugs, performance, security issues, coupling, so on and
so forth.

OO code can be bad yet contain no debuggable issues. Once it's laid out, noone
is going to "fix it" because it's not technically broken. It'll just rot due
to lack of maintenance, until there's noone left with a good mental map of it
and enough of the non-OO contents are broken enough that it gets replaced all
at once.

------
greenleafjacob
Things aren't unconditionally necessary except in modal logic. In the real
world things are conditionally necessary. Clean code is necessary... for
ongoing development. Clean code is necessary... to allow developers to onboard
quickly. Clean code is necessary... for reducing the cognitive overhead and
avoiding mistakes.

Unfortunately without stating these assumptions it's impossible to prioritize
and be rational about development. It provides no guidance. Should we drop
everything we're doing and "clean up" the code? Is it even worth investing in?
These are questions that have different answers depending on the assumptions
and simply saying it's "necessary" is insufficient.

------
retrogradeorbit
Clean code is not an OO concept. It's a higher level concept. SOLID may help
you achieve clean code in OO, but clean code does not mean "know SOLID".

~~~
exclusiv
I agree, but for the bulk of software engineers it's probably on point.

For many of us, it's nothing new, but I do think that it's remarkably easy to
just rip code toward a deadline unconsciously without keeping these concepts
in mind.

If you do backend, the user doesn't give a shit about your clean code, so
sometimes it's a trade-off in deciding your approach knowing the lifetime
requirements and maintability needs of a project which only comes from
experience.

~~~
maze-le
> If you do backend, the user doesn't give a shit about your clean code

It's not about the user. Coding in a 'clean' way is something you do for your
colleagues and maybe future colleagues, who will have to maintain and upgrade
your software in the future.

> so sometimes it's a trade-off in deciding your approach knowing the lifetime
> requirements and maintability

I have seen quite some hacks that were intended as 'one-time-only' and 'we-
refactor-this-later' solutions. I don't think any of these trade-offs payed
out in the end. The proper work to refactor crappy code and reintegrate it
into the system took a whole lot of time longer than implementing it correctly
in the first place.

The only situation where hacks like this are acceptable in my opinion are
'one-time-only' prototypes (where the prototype code does not find its way
back into the codebase), where certain features are shown to a customer, and
the rest are mockups.

~~~
warcode
Often I find that clean code is something I do for my future self too. Having
some external factor break your algorithm and coming back to multiple nested
loops and "i,j,k,l,x,y" variable names makes it take way too long to fix.

~~~
DonHopkins
Oh _cringe_. Please don't use "l" as a loop index! Don't use it for anything!
Make it go away!

------
mehwoot
_Liskov Substitution: An object can be replaced by supertype without breaking
the program_

Shouldn't that be _sub_ type? Or am I misremembering this?

~~~
humanrebar
Many developers, myself included, aren't fans of the Liskov Substitution
Principle because base classes aren't a great way to reuse code.

Prefer composition over inheritance for reuse. And prefer interfaces over base
classes (abstract or concrete) for polymorphic behavior.

There aren't many situations where Liskov is even relevant with those
principles in mind. I have to inherit from a concrete type from time to time
when when a third-party API requires it. And, inevitably, my design becomes
more convoluted than necessary because of that.

~~~
bunderbunder
The problems with subclass inheritance aren't a challenge to LSP. They're an
illustration of exactly what LSP is about.

In order to make it easier to follow LSP, it's wise to minimize the amount of
concrete implementation in your base types. The more you can minimize it, the
less likely you are to encounter a situation where a base type implements
behavior you don't want. That in turn reduces the spots where you might even
want to violate LSP.

The logical end to this is purely abstract base classes which contain no
implementation. These types are so easy to reuse that some languages have even
enshrined them as their own special language construct (typically called
"interfaces"), and given them special privileges that types which allow
implementation don't get to enjoy, such as multiple inheritance. The reason
they get these special privileges is that it's relatively easy for them to
enjoy those features without violating LSP, whereas it's inherently tricky for
types that include concrete implementation to do the same.

~~~
humanrebar
I wasn't challenging the LSP as much as saying it's practically moot, at least
for me. To that end, the digression into ABCs and LSP only gives inexperienced
developers a digression to explore on the way to cleaner design principles.

It's also worth noting that ABCs are especially problematic when physical
representation of data is concerned. Inheritance in C++ affects memory layout,
for instance. And adding new serializeable members to a base class in any
language is a reverse-incompatible change.

~~~
bunderbunder
If there's any physical representation, then it's not all the way there on the
abstraction front. I meant to exclude any definition of storage format with
the "that contain no implementation" qualifier, because specifying data
members is necessarily specifying how you expect the storage of that
information to be implemented.

As a contrasting example, Java and .NET interfaces aren't allowed to contain
fields, only method and property signatures. Which really means only method
signatures, since Java and .NET properties are just methods + syntactic sugar.
Both languages also have ABCs, but they are distinct language constructs that
don't get to enjoy the same privileges as interfaces.

That may mean that C++ abstract base classes don't quite hit it on the LSP
front. It's also true that C++ is a language that predates LSP's formulation
by over a decade, so we can't really expect it to be a language that's
designed to take LSP into account, anyway.

Long story short, though, just because LSP is baked into your programming
language doesn't mean it's moot. It just means you're working in a language
that's well-designed on that front.

------
mdmoss
I think the author's statement of the Liskov substitution principle is
backwards; An object must be replaceable by a subtype, not a supertype.

~~~
coderjean1
Yes you are totally right. I mistyped a word. Where it says supertype I
actually meant subtype. I corrected the article.

------
berntb
Today a discussion like this make me so jealous I get vertigo... :-)

Yesterday evening I spent two hours just to trace and understand the dispatch
for a really simple and small part of a big, old web application.

(To save time, the answer to the question you want to ask is: "Yes, glad you
asked. It really is from 1999. And no, they don't know the word refactoring.")

~~~
DonHopkins
At least it's a good excuse to put on a Prince album while you work.

~~~
berntb
My music of the time was more singer songwriters, balkan gypsy, modern jazz
and death/black. :-)

------
k__
Encapsulation and modularization is necessary, nothing more.

If you get this right, you can get away with a bunch of crappy thing, because
you can easily throw them out in the future and reimplement them better.

~~~
stinos
Really _nothing_ more? I beg to differ after having to plough through lines of
code just yesterday where, just to give some examples

\- each single line uses a different formatting style

\- variable names are hard to read abbreviations

\- variable/class names don't make sense

\- 5 is a level of indentation easily reached

\- there's almost as much dead code as live code

\- comments are grammatical nonsense and don't explain why the code is written
the way it is

~~~
k__
Can all be fixed rather easily, if there ha been good modularization.

But yes, I prefer those things too, haha

~~~
cauterized
But to replace code, first you have to understand it.

~~~
k__
Modules have an api and a responsibility, often this +any code helps to
understand whats going on good enough

------
raverbashing
"Clean code" at this point in time sounds more like a inside joke for uncle
bob fans to satisfy themselves with

"Clean code" sounds a lot like "True Scotsman"

SOLID is better but it still is subject to some subject interpretation

------
snarfy
It only matters if you value the code. Nobody cared if Space Invaders source
code was a ball of mud that was hacked together once and never looked at
again. It still made millions of dollars.

------
Bahamut
As with everything, it depends on your requirements, including timeline,
shelf-life of application, and future maintenance/feature building.

Sometimes, code is a one-off and it is better to write something that works
rather than worrying about the perfect implementation.

One should strive for clean code when one can, but all things have tradeoffs
that have to be decided for/against.

------
scotty79
> Open-Closed: A class should be open for extension, but close to modification

I hate when people do this. Closing class for modification is very easy, but
opening it for extension requires predicting the future, which is impossible.
Which coupled with being closed to modification destroys re-usability.

------
coldcode
Clean code does not matter by itself; comprehensible code does. If you
understand what you have you can reason about when it might go bad and avoid
it; even if it does fail you can understand why and fix it; you can see what
you need to do to modify it in the future. That's what matters.

------
hacker_9
Depends on the definition of necessary. If you consider living a pleasant life
necessary, then the answer is yes.

------
dsego
TLDR: Yes.

~~~
arpa
And here I was expecting something that will shake the core beliefs and uproot
good ole Uncle Bob; alas, not the case, yet another "Yes, clean code is good,
unclean baaad"; I mean, the concept is great and all, but damn, stop preaching
to the choir, it will get us nowhere...

------
caleblloyd
Is Clean Code Possible? Not if you're writing ES5 JavaScript for the browser.

~~~
jomamaxx
This comment should not be downvoted.

It's a hard realpolitik of web programming.

