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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
🤗🤗🤗 then I couldn't agree with you more
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.
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.
Ah, my mis-understanding Paula. Totally agree with you then.
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".
Here are some additional resources about minimalism that I found useful:
I forgot to include Get rid of it 🤦♀😂, the app that we build and was on the US news!!
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.
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.
Excellent tips! I follow these myself.
My only addition...
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.
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! 🙏
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 😂
Did you mean Mustache Matt? :D
That's ok, just promise me you won't do it again 😂
And yeah, Matt is awesome!
"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.
That's right, mindfulness all the way!
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?):
You're absolutely right. Your suggestion is clearer and sounds better too, I'll change it. Thank you, Mike!
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.
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.
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
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!
Thank you Paula to share us how we integrate minimalist lifestyle in software development
Thank you, Emmanuel!
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.
Thank you!
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!
Thank you, Filipe!
That book has been on my reading list for so long! But I still haven't read it 😔.
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 :)
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.".
Thank you! Just fixed the typo, can't believe I didn't realize after reading the whole thing like 10 times 😂
This is great -- excellent points, very well made. Thanks.
Thank you, Nick 🙏
Great tips! Thanks for sharing.
I like the article but would suggest changing your "click here" link to something descriptive for accessibility purposes.
Great suggestion Ben, I hadn't thought about it that way. I'll fix it ASAP.
Thanks!
Good post. I found Matt D'Avella on Youtube about a year ago and enjoy watching his videos.
Me too, his work is amazing and constantly getting better. Thanks for stopping by, Dana!
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 ❤️
Guilty! Thanks for sharing!
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!
Great article Paula! Especially agree with the commented code point.
Thank you! 🙏
In few words, develope in Clojure :)
I'll have to check it out!