4 ms·
What is easier to read: a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 b) 20 If all the code in your project was written li
by 29athrowaway 4y ago
What is easier to read:
a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1
b) 20
If all the code in your project was written like a), how would you feel? Does it make your job easier or harder?
I'll tell you how most people feel when they read code that looks like a):
- The author didn't care about other maintainers.
- The author is selfish and does not have empathy for others.
- The author ruined my fucking day.
- Team members are competing by sabotaging each other's productivity.
- If I clean this, by the time I am done, the author would have pushed 10 more commits that look exactly like this and eventually become my boss.
- The author is wasting everyone's time.
- The author is forcing others to volunteer to clean up after them.
- Why does management tolerate code following the a) style? A simple intervention would make it go away and my job would be so much better.
- It's sad that everyone is too busy looking at Jira and nobody cares about the actual fucking product.
- This is slowing everyone down and I have stuff to do.
- The code is error prone, one day I'll break it.
- Why should I contribute quality code if low quality is acceptable?
As you can see, it objectively fucking sucks. It's draining, demoralizing to read, it's frustrating, it wastes people's time, it gives people the perception that nobody fucking cares and the code is everyone's toilet with no trip lever.
And while it's "superficial", it's the surface that all engineers interact with. If I spread superglue over the surface of your kitchen counter and every dish and utensil in your kitchen every day around lunch time, that problem will also be "superficial", but it will ruin your life.
So, the conclusion is: Just fucking write clean code. Shitty code ruins the morale of people who care, who are the people that want to build great things not the ones cashing a paycheck and resting and vesting.
You are not a full-time architect, you are not in business development/marketing/finance or whatever, you are in the fucking engineering department. Your contribution to the business are your deliverables. The "superficial" stuff you talk about is your job. Do it.
"Ah ah ah, you didn't say the magic word!! ah ah ah!" Don't be the fucking Dennis Nedry of the team. Format your code, make it readable by your team and your future self.
Do you want everyone to love you? Write code like this:
https://norvig.com/spell-correct.html https://norvig.com/spell-correct.html
- jstimpfle 4y agoWhat the f* is wrong with you?
- deleted 4y ago[deleted]
- mod 4y agoIf your comment were code, I think it's an example of a)
- 29athrowaway 4y agoFair enough, but a strong point had to be made.
- teo_zero 4y agoYour example is artificially designed to make your point, but imagine a case like this: # Add the left & right margins width = calculatedWidth + 1 + 1 The "+1+1" might indeed be more readable than "+2".
- alpaca128 4y agoYes, I sometimes do that as well to signal a part that's non-obvious or easy to overlook. Ideally with a little comment for the reason. Same with my (admittedly rather dirty) openSCAD designs, where I like to explicitly add tolerances to the measurements while keeping them separate, e.g. `width = 34 + 0.25;`. Especially because tolerances often have to be tweaked a couple times.
- 29athrowaway 4y agoYou miss the point. The problem are not arithmetic operations.
- teo_zero 4y agoSorry if I've misunderstood your post. The parent article was about replacing dense code with more lines of simpler syntax. I assumed you were in the shorter-is-better camp and willing to prove it with your example, where shorter undoubtedly is better. I found your example far stretched, and designed another case using your material (arithmetic operations) but applying only 2 repetitions, much in line with the spirit of the fine article. I hope I managed to show that, although we can agree that "very very longer is worse", this not always implies "shorter is better".