131–140 of 224 posts
Learning that you can deduplicate code.
Learning that deduplication causes coupling.
Learning how to inject behaviors.
Learning how to discuss problems before job hobbying someone else's code.
Learning that all code is really not what the end user cares about. They only care that it works and corporately you want to do it as cheaply as possible, privately you want to remain employable and increase your marketable skills. Everything else is a distraction.
This post is such a breath of fresh air! I'm glad I'm not the only one who has come to realize that a lot of "clean" code is actually just developers trying to be clever or scratch an itch of obsessive-compulsion. Repetition isn't necessarily a bad thing. If the repetition isn't difficult to alter and it more clearly describes what is happening on a step by step basis, it's difficult for me to call that "dirty". Code…
Flexibility should be kept in mind. In the blog post example I would have at least abstracted the math out and there's no reason of the limitation of one handle function, you could swap them out.
Yeah I may a be a bit OCD, no I'm not trying to be clever. I'm trying to reduce complexity so I can keep the entire system in my head to optimize things easier. Don't atomize everything into tiny functions though, there's a huge middle ground.
No book gets everything right, but I recommend The Pragmatic Programmer for this sort of thing.
People seem to use wrong instances of people "cleaning code" to justify dirty code and tech debt.
"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…
That said, despite the clickbait title, I think these sorts of posts make a valid point because people often do in fact take heuristics like DRY to mean "never repeat any code under any circumstances and any code repetition is per se bad."
Earlier quoted context omitted.
And yet, at least for the quoted part, he is right. It requires some massive balls to deploy code to production while not even seeing if it works for any case. If the answer to "how do you know it works?" is "trust my judgement bro" then I will not, in fact, trust their judgement. I do agree he has a finger in the zealotry and he should probably have modulated how he expressed himself.
You know, they sent people to the moon using software written before the unit test paradigm.
I haven't actually read his site, I'm going by what was quoted.
Might be that he meant "unit tested" when he said "tested", I guess.
Some duplicated code is okay, but duplicated math code seems more risky than duplicated CRUD code or other business logic. Math code/functions seem easier to unit test to me, deal with much simpler data types, and are a great use case for unit tests unlike CRUD code. CRUD and business logic often has dependencies that must be mocked too and math functions can likely be pure. Math code also seems way more amenable to…
It's not just about reducing lines of code and increasing abstraction, which I agree are bad metrics. It's about legibility. He took a block of 140 lines of dense math descriptions of objects, and reduced it to nicely structured semantic code. It's a 100% improvement, if that code has a bug, anyone could read it and find it.
The author said they would later need support for different behaviour that would have made his code more convoluted. Well big deal, it's not like there was a way to do it without violating open/closed anyway. This code is so easy to understand, anyone can read it and go "ah this won't work with the new requirements, let's delete it and start over".
Not saying this code 100% needed to be refactored, but if you're an engineer and you see it and you think you have some spare energy to pretty up a piece of the codebase, and you diligently test and verify your implementation, why not do it?
I wish my team would do this more often.
Firstly, was there any kind of review or just a chance for team members to talk about the original implementation before it got onto master? After the fact?
Second, Ok, the master commits seem liberal, but why then the boss goes the one-on-one way to make a team-member purge the commit? It seem like a wasted chance at regreasing the team dynamic, let developers find a way to forge the code together.
There should be an open channel between devs and also a way for them to express themselves by means of code... without fear of blame or dangers to the mainline. 'Branches are cheap', isn't it? Personal-branch it so it could later be showcased to others, to the boss?
IMO, this is more about Open Team, than Clean Code.
Having duplication does not mean your code is not clean. Sometimes, having duplication is actually cleaner, and easier to understand. Removing duplication may introduce complexities, and force developers to untangle the additional logic that was introduced to remove dupes. Good duplication means code just happened to be the same in a few places (but it can be potentially different). It's fine and easy to read. On the…
Additional logic is only needed when code is almost duplicated, and that is where the question arises of whether what is happening is best viewed as a different “version” of some common process, or a different basic process that has similarities.
Actual duplication doesn't require additional logic to remove duplication; and even near dupes often don’t require distinct (i.e., branching) logic if the language offers the right abstraction facilities.
This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
"hey we need feature X" (feature X is 2 lines of code).
"Ok, I've made 4 layers of abstraction, and 2 interfaces! an extra abstract class!"