DEV Community

Cover image for 6 ways minimalism can help you write clean code

6 ways minimalism can help you write clean code

Paula Santamaría on September 18, 2019

Introduction In this article I'll share how you can apply minimalism concepts in code to make it clean and be more productive. If you a...
Collapse
 
kenovienadu profile image
Ovienadu Ken

It's a beautiful piece. You're very correct. Commented code looks ugly and makes the code difficult for others to read and understand.

You mentioned the dependency clutter. But then you also encourage code reusability. Can you please clarify on this.

Collapse
 
paulasantamaria profile image
Paula Santamaría • Edited

Thank you Ken!

When I was talking about reusability I was referring mostly to reusing your own code. Like, for example, don't write the same function twice with a different name.
But I'm also in favor of reusing code through dependencies, as long as the cost of integrating that dependency is worth taking.
Like with any form of minimalism, there's no "one size fits all", it's about being aware of the cost vs value ratio in your particular case.

Collapse
 
kenovienadu profile image
Ovienadu Ken

🤗🤗🤗 then I couldn't agree with you more

Collapse
 
theweeappshop profile image
Tony Ross

Disagree about commented code; but there's a time and a place for it. If you have the capability to minify your code, then comments have no place. However, in the overall readability/understandability of a large system, and to assist with debugging, comments are invaluable.

Great article though.

Collapse
 
paulasantamaria profile image
Paula Santamaría

I may have explained myself poorly on that point. I meant that commented-out code has no value. I'm in favor of comments that explain the purpose of code, as long as they add additional value.

Thread Thread
 
theweeappshop profile image
Tony Ross

Ah, my mis-understanding Paula. Totally agree with you then.

Thread Thread
 
moopet profile image
Ben Sinclair

Commented-out code may sometimes - very rarely - have value, but usually as a warning not to do something. Like in a function document string, something saying "this used to be done like so, but there's a gotcha, so don't refactor it back".

Collapse
 
mauro_codes profile image
Mauro Garcia

Here are some additional resources about minimalism that I found useful:

Collapse
 
paulasantamaria profile image
Paula Santamaría

I forgot to include Get rid of it 🤦‍♀😂, the app that we build and was on the US news!!

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

Excellent tips! I follow these myself.

My only addition...

Commented code is just noise: It's not useful to the software, it's distracting to the people reading your code, and it's just not pretty. Get rid of it!

I'd apply that only to comments describing what the code is and how it does it. Commenting intent ("why") has proven to be a massive time-saver for both myself and anyone else reading or working on my code. More about that here.

With that said, what you described with commenting is otherwise spot-on.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Couldn't agree more. Comments explaining the purpose of the code are totally ok, as long as they provide value (which I believe they do). I even wrote an article about writing comments to document your JS code using JSDoc.

Thanks for your comment, Jason! 🙏

Collapse
 
shymi profile image
shymi

I love the 3-rd point. A while ago we had to deliver to a client a minimal part of the product, which was rewritten from 0. The first thing, that our architect told us, was "Don't try to guess what will be the next requirement. Just cover the current ones". Working in a software company can be a dynamic job and no one knows what will be the next big thing, that the client would have interest in.

Collapse
 
paulasantamaria profile image
Paula Santamaría • Edited

Thanks for stopping by, Shymi!

Completely agree. It's hard enough to complete the required work on time, it'll be even harder if we keep adding requirements ourselves! 😅
Sometimes we think that the extra-work will be appreciated by the client, but it usually leads to incomplete features that give the impression of instability.

Collapse
 
dimitriszx profile image
Dimitris Zarachanis

Some really great tips here! I plead guilty of leaving commented code just in case. Also, I have never expected to find Matt d'Avella here 😂

Collapse
 
mauro_codes profile image
Mauro Garcia

Did you mean Mustache Matt? :D

Collapse
 
paulasantamaria profile image
Paula Santamaría

dramatically disappointed

That's ok, just promise me you won't do it again 😂

And yeah, Matt is awesome!

Collapse
 
mikeschinkel profile image
Mike Schinkel

Great article, agree with it all.

One comment through; your title for #2 made me think you were arguing to not comment code rather than what I realized were you arguing after reading closely; i.e. not leaving commented-OUT code in your commits.

Maybe consider changing the title to (I reworded to keep it short?):

"Commented-out code rarely has value"

Collapse
 
paulasantamaria profile image
Paula Santamaría

You're absolutely right. Your suggestion is clearer and sounds better too, I'll change it. Thank you, Mike!

Collapse
 
pierreturnbull profile image
Pierre Turnbull • Edited

"Don't do stuff just because "we have always done it this way""

I would add this:

"Don't do stuff just because "we have always done it this way", or because "everyone else does""

Although an idea's popularity can be a useful indicator of its relevance, it is never a proof that it is ideal (or worse, ideal in your specific case).
This is a mistake that some people do, probably to avoid thinking, and it sometimes causes them to make terrible decisions.

Collapse
 
paulasantamaria profile image
Paula Santamaría

That's right, mindfulness all the way!

Collapse
 
xwero profile image
david duymelinck • Edited

Commented code is a thing from the time before version control solutions.
I stopped doing it when i started using subversion.
But there are codebases I inherit from other developers. Most of the time I just remove it when I start working with the code in one commit.

There are rare occasions where commented code is a convenience. In those cases I add the comment tag KEEP_CODE followed by the date. I do a periodical check for this tag and get a report for code that is older than a month. That is my expiry date for commented code.

Collapse
 
paulasantamaria profile image
Paula Santamaría

That's a nice tip. Last week I was looking for an ESLint rule to detect commented code and I run into a Github issue where they discussed that there're some cases where commented out code may be useful, like code usage examples. I have to agree that it's not a black or white thing.

Collapse
 
xwero profile image
david duymelinck

The case that comes to mind at the moment is when the client is a/b testing features and they are not sure if they want to keep it of remove it after the testing. When my report comes in I mail them about it, and most of the time they will have a definite decision.

The only time I would put code usage examples in commented code, is when the project has a comments to documentation parser like JSDoc

Collapse
 
emmbyiringiro profile image
Fiston Emmanuel

Thank you Paula to share us how we integrate minimalist lifestyle in software development

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you, Emmanuel!

Collapse
 
filipecsoares profile image
Filipe

Hey, congrats! Great post! This post remembered me about the book Clean Code, very useful and your suggestions are very good too, I already watched this documentary.

Thank you to share it!

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you, Filipe!
That book has been on my reading list for so long! But I still haven't read it 😔.

Collapse
 
filipecsoares profile image
Filipe

I understand you. There are a lot of great books out there, It's really difficult to decide which one read first. I hope you read that one soon :)

Collapse
 
ical10 profile image
Husni Rizal

Hi. I came here after watching Less Is Now on Netflix.
A well-constructed article indeed. I agree with your points there. I'm only in my first year as a software dev so I consider myself lucky discovering this quite early during my career.

Can't wait to read your next pieces!

Collapse
 
enriqueedelberto profile image
Edelberto Enrique Reyes

Thanks a lot for your post.
For me, the best part is "Don't write code just in case", because sometimes we think that something can help you in the future, but, you add more unnecessary code.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you!

Collapse
 
wizardrogue profile image
Joseph Angelo Barrozo

There’s usually no value in commented code

Guilty! Thanks for sharing!

Collapse
 
paulasantamaria profile image
Paula Santamaría

Oh I was certainly guilty of all of the above at some point! But being aware is the first step, then comes the improvement 💪
Thanks for your comment, Joseph!

Collapse
 
nhatnguyentim profile image
Hoang Nhat

Great article, I love minimalism and always apply to the way I code, and also the way to choose between complicated vs simple but efficient solution for a problem. Thanks for sharing ❤️

Collapse
 
malagutti profile image
Anderson

Great tips! Thanks for sharing.

Collapse
 
moopet profile image
Ben Sinclair

I like the article but would suggest changing your "click here" link to something descriptive for accessibility purposes.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Great suggestion Ben, I hadn't thought about it that way. I'll fix it ASAP.

Thanks!

Collapse
 
dana94 profile image
Dana Ottaviani

Good post. I found Matt D'Avella on Youtube about a year ago and enjoy watching his videos.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Me too, his work is amazing and constantly getting better. Thanks for stopping by, Dana!

Collapse
 
lmolivera profile image
Lucas Olivera

I really liked your article Paula! You have a typo, sections "Take advantage of what you already have" and "Avoid "shiny object" syndrome" both start with "5.".

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you! Just fixed the typo, can't believe I didn't realize after reading the whole thing like 10 times 😂

Collapse
 
nickhodges profile image
Nick Hodges

This is great -- excellent points, very well made. Thanks.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you, Nick 🙏

Collapse
 
jeastham1993 profile image
James Eastham

Great article Paula! Especially agree with the commented code point.

Collapse
 
paulasantamaria profile image
Paula Santamaría

Thank you! 🙏

Collapse
 
luisccc profile image
LuisC

In few words, develope in Clojure :)

Collapse
 
paulasantamaria profile image
Paula Santamaría

I'll have to check it out!