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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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).
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
I see what you mean. I suppose is about balancing between good and clean practices and simple enough implementations.
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
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.
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.
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.
Thank you!
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..
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.
I try to do this as well, makes it easier to read.
This is the case where you'd really scratch your head when encountered.
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.
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
ifin 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.
🤓😅
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.
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 😂
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.
An article about clean code from the business point of view sounds truly interesting, I'll definitely stay tuned!
Thank you, Gerard!
This is a really great framing of the topic.
Thank you, Ben!
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.
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:
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.
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"
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 :)
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.
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.
I remember watching a documentary about it but I'd completely forgotten the name of the theory. Thank you Todd!
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)
Done, thank you!
Btw function calls are expensive
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! 🤗.
Thank you, Luke!
Bravo, perfecto!! :-D
Quick note: first link at the top of the article is broken.
Nice catch, thank you!
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.