DEV Community

Cover image for Clean code... Why bother?

Clean code... Why bother?

Paula Santamaría on September 28, 2019

Last week I wrote about how minimalism can help you keep your code clean, but as I was writing I realized that something was missing. Writing clean...
Collapse
 
elasticrash profile image
Stefanos Kouroupis

I kind of disagree on point 3. So far in every company I worked for, in the first phase we always write a quick and messy poc to see if our idea is indeed achievable. Once the second phase gets approved, I always had the opportunity to refactor it properly. In rare cases when the pic is an insane mess, I was always aloud to start from scratch. No one willingly wants to write shit code.

Collapse
 
morgenpeschke profile image
Morgen Peschke

As long as you set the expectation that version 0 is intended to be thrown away from day 1, this works.

If on day 120 the team figures out this unspoken assumption isn't shared, things fall apart.

Collapse
 
paulasantamaria profile image
Paula Santamaría • Edited

Hi Stefanos, thanks for your comment!
To be honest, I never worked in a company that followed that kind of process. I don't doubt it works for you and your team. But, in my opinion, writing a fast POC and using clean code principles are two things that can easily coexist whitout interfering with one another. Once you know naming your functions correctly is important, why would you do otherwise? How would that speed up the process?
The third point is specially important when you work with beginner devs in the same team. After all, every code you leave for them to work with serves as example. Checkout the broken windows theory (mentioned by @eidsonator in another comment).

Collapse
 
elasticrash profile image
Stefanos Kouroupis

You have a point on naming. But naming is the least of the problems and by far the easier to amend. I was referring about concepts like SOLID principles, well thought abstractions, patterns etc

Thread Thread
 
paulasantamaria profile image
Paula Santamaría

I see what you mean. I suppose is about balancing between good and clean practices and simple enough implementations.

Collapse
 
ehorodyski profile image
Eric Horodyski

You're lucky! Most places I've worked see a POC and want to rush to the next step.

That's why it's important for us as developers to manage up. We need to advocate for some extra time to do POCs the right way because it most likely become production code

Collapse
 
elasticrash profile image
Stefanos Kouroupis

The only complains I have from our process is that a. the poc allocated time spans between 2 to 4 weeks in order to decide whether a ~2 years project is feasible... b. between the poc and the actual start of the project there is barely enough time to properly design it. Thus following certain practises as the article suggests is highly recommended

As of lately though things have improved by a lot.

Collapse
 
mikeschinkel profile image
Mike Schinkel

Just wanted to state a counter-argument here, and say that point #3 resonated with me more than any other.

I am currently refactoring a code base for a client that is outrageously messy. And why? Because the original developer was messy and the people that followed him just copied his style. Now we have huge functions, one of them 1400+ lines long.

I guess I should not complain. They are paying me very well to clean it up.

Collapse
 
rconr007 profile image
rconr007

Thank you. This is really a great post. I am in total agreement. Clean code requires more of your time and thought process at the beginning but it makes up for avoiding a wind world full of headaches and time wasters.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you!

Collapse
 
yucer profile image
yucer

Better naming the identifiers is one of the harder tasks

It would be good to research more about how that affects the understanding of the code.

For example giving negated names for boolean variables like: no_update

When negating that it would be:

if not no_update then...

It would be better:

if update then..

Collapse
 
ehorodyski profile image
Eric Horodyski

For me, name booleans with question identifiers. Like "is updated" or "hasBeenUpdated". Then you get code like "if(hasBeenUpdated)" and it makes more sense linguistically. However, if you work with members who aren't super fluent in English it becomes tough, because English is totally a tricky language.

Collapse
 
paulasantamaria profile image
Paula Santamaría

I try to do this as well, makes it easier to read.

Collapse
 
sshanzel profile image
Hansel Solevilla

This is the case where you'd really scratch your head when encountered.

Collapse
 
okbrown profile image
Orlando Brown • Edited

I find this topic annoying at times. Because we are all different and hardly agree on what "done" is or what "clean" is.

I now let the definition of what the "product" decide on how I should proceed.

Once that product has a clear understanding of what is required, then experience follows with what the appropriate architecture looks like, thus the tech, the principals and standards that should follow.

How about ensuring a one function one thing (sounds familiar 😏) principal which will allow for easier changes or modifications as the "product" evolves.

And if there is more than one if in your function STOP!...

Last thought... If we actually took time "to measure twice and cut once" we would spend less time refractoring and bug fixing.

🤓😅

Collapse
 
davjvo profile image
Davmi Jose Valdez Ogando

Clean code and architecture always leave me thinking, how far should we go for it?

I've had cases where a team member obsessed with this would make it really hard for everyone else to follow up the flow of an app.

Collapse
 
gjaryczewski profile image
Gerard Jaryczewski • Edited

Faster decision making - I did't notice this advantage until now, thank you. By the way, it is only one advantage at this list which is important for non-developers, especially for management. So I have an incentive to expand this list from the business point of view. I stay tuned.

Collapse
 
paulasantamaria profile image
Paula Santamaría

An article about clean code from the business point of view sounds truly interesting, I'll definitely stay tuned!
Thank you, Gerard!

Collapse
 
jeastham1993 profile image
James Eastham

Another great article on clean code, and one I agree with in its entirety.

One of the rules I try to follow is the 'boy scout rule'. Every time I check out and make a change to some code I always check it back in cleaner.

I think one of the most important things for clean code is a good set of unit tests with code coverage. That way you can clean to your heart's content without worrying about introducing breaking changes.

Collapse
 
paulasantamaria profile image
Paula Santamaría

You're absolutely right. I try to always go through my changes before commiting to verify that everything is nice and clean. Haven't thought about it before, but I guess I follow the 'girl scout rule' myself 😂

Collapse
 
ejrojasb profile image
EmilioJRB

Great post. I totally agree on every point.
The time it takes to do clean coding is the time you are saving others or even yourself to modify the funtions or scaling them. And not only that, it even helps you seeing the purpose even faster and look for flaws and alternatives.
I think is a "must" and not a "could"

Collapse
 
amitnovick profile image
Amit Novick • Edited

I like the idea behind this post.

That said, in general, code sucks as a medium for informal reasoning (the kind of reasoning where you try to understand something's behaviour by observing it). On top of that, our tools (text editors, CLI programs, version control systems) are heavily code oriented which makes changing the status quo pretty hard.

The best we can achieve is either:

  1. Write code that is supposedly easier to understand
  2. Use code only as a low-level source for generating other artifacts which we can understand more easily: e.g. state machines or statecharts (images not my own).

These days when developing JavaScript I like to use XState for generating (✨ interactive!) graphs from my code. The benefit of such graphs is being able to understand how stuff work before adding features / making changes, and thereby avoiding common pitfalls that become obvious as soon as you look at the visualized graph, but are easy to miss with just code alone.

Collapse
 
dzoeller profile image
Dan Zoeller

The only legitimate reason on that list IMO is #6. No one is going to thank you for clean code. Eventually, you will be out of the picture and someone is going to rush around to add a feature and the code base will get messy, they will start naming things however they want to. So do it because it feels good and you know it's right :)

Collapse
 
paulasantamaria profile image
Paula Santamaría

For me, the #6 summarizes all the others in a way. I do it because it feels great to take advantage of all these other things.
I do code reviews and PR reviews regularly and I do feel thankful every time I have to review clean code 😂
Altough, your comment made me think that I should actually say "thank you" to the dev more often.

Collapse
 
ben profile image
Ben Halpern

This is a really great framing of the topic.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you, Ben!

Collapse
 
eidsonator profile image
Todd Eidson

Great article. I'd always heard number 3 associated with the "broken windows theory". That's a good subject to read up on, if you haven't already.

Collapse
 
paulasantamaria profile image
Paula Santamaría

I remember watching a documentary about it but I'd completely forgotten the name of the theory. Thank you Todd!

Collapse
 
thesigitprayoga profile image
Sigit Prayoga

I once refactored numerous lines of code and it gave me a headache (figuratively) and I did a git annotation there, I was surprised -- it was my code 2 years earlier when I first wrote them.

Writing clean code is not the first step of your career as software engineer.

Collapse
 
yucer profile image
yucer

You can add python code conventions:

python.org/dev/peps/pep-0008/

I like also the tools that verify the code against those community standards (linters)

Collapse
 
paulasantamaria profile image
Paula Santamaría

Done, thank you!

Collapse
 
nilshochschwender profile image
NilsHochschwender

Btw function calls are expensive

Collapse
 
lukegarrigan profile image
Luke Garrigan

Love it, couldn't agree more! This blog was just the inspiration I needed to get my sh*t together and clean up an old feature I'd botched together. Thank you! 🤗.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you, Luke!

Collapse
 
alexandis profile image
alexandis

Bravo, perfecto!! :-D

Collapse
 
byrro profile image
Renato Byrro

Quick note: first link at the top of the article is broken.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Nice catch, thank you!

Collapse
 
davjvo profile image
Davmi Jose Valdez Ogando

That's where I wanted to get sorry for not being clear.

Sometimes we got so deep in architecture rules, conventions, our own environment limitations. That we forget about clean coding.