141–150 of 395 posts
Earlier quoted context omitted.
Look more carefully, there's no contradiction. Splitting a method into several independent methods doesn't mean you repeat yourself.
The flag check could be deep within a loop, how would you split it then without repeating the whole method?
Earlier quoted context omitted.
> Don't comment out code, just remove I hate commented out code, but this doesn't work in every situation. While working on a clinical information system, we had frequent "please bring it back" requests that came a few months after things were removed (also by request). Relying on source control is nice, but unless you document every feature/removal or use very extensive commit messages, finding the code that was rem…
Seems garbage advice to me. Now you've polluted your production code, likely forever. I don't see a situation where using an issue tracker + good commits - e.g. 1 commit for the 1 PR linked to the ticket that removes the feature - won't result in a superior situation from a maintenance and traceability perspective.
You can guess, but that will leave you with many classes/functions commented out only in the hope that one day one of them will be requested to be put back. This leads to nobody daring to remove old code for months/years.
Then, one day, a new coder on the team just ask WTF is this here, realize it's outdated and not running anymore, and will remove the whole thing. Then, the "senior" guy on the team comes shouting at him/her: "We might need it one day, what do you know about our team, bla bla bla, we had a feature 4 years ago that was removed and we had to add back, so now we have the rule of commenting things out". Yuck, what a nightmare.
Just create good commit messages, don't group irrelevant changes together, and you'll be able to find the commit if you really have to. And even if you can't, you know you can still just develop that thing again, right?
Earlier quoted context omitted.
> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…
> One assert per test I read that as "one operation per test". Specifically, both: assertEqual(complex(1, 2) + complex(3, 5), complex(4, 7)); and: auto c = complex(1, 2) + complex(3, 5); assertEqual(c.re(), 4); assertEqual(c.im(), 7); would both satisfy that requirement, but: assertEqual(complex(1, 2) + complex(3, 5), complex(4, 7)); assertEqual(complex(1, 2) + complex(-3, -5), complex(-2, -2)); would not. -- In that…
So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…
So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…
> >I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
That's beautiful advice. Something similar that I heard was "flow of data > dependencies > interfaces", in terms of what to worry about. Interesting how they're so similar but from different sources.
But yeah, I second your experiences. Focusing on this stuff, like in code reviews for example, ends up making all other downstream concerns so much easier.
So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…
This is a generally good idea, but in small teams it can't really work. Code is in that sense a bit like handwriting, everyone has their own style, and after a long enough time in a small team you learn to recognize whose the author of the code just by reading it.
Coding is a highly subjective and creative endeavor. "Clean code" is akin to "well written" for writers. Sure, you can analyze and even be able to define some good practices, but because we are always creating something new that has never done before, and the field is infinitely complex, no rules can be set in stone and applied across everything. In my opinion there's nothing wrong with calling code clean, we don't h…
Earlier quoted context omitted.
> Hide internal structure (that "private" is the default in C++, Java and Rust just adds to boilerplate; the default case is that you want everything public (unless you like writing trivial getters and setters just for the fun of it); legitimate uses of "private" exist, but are rare) This is such a strange POV to me. There are cases where your classes are just data records, but any object with logic surely wants to r…
IME I write about 10-20 as many data records as "classes". I do use "private" from time to time to protect invariants. But if the default was switched to public, my code on balance would be a lot shorter and readable. I'm not saying that "private" shouldn't exist. I'm saying it's a poor default.
The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…
> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…
The title is click-bait but the conclusion makes sense. It's just unfortunate that most people have such different ideas about what 'clean code' means. I guess people will ascribe that label to any code which they produce. Everyone (regardless of actual competence) wants to think of themselves as a good developer who writes clean code. My own definition of 'clean code' means maintainable (anticipates some broad futur…
"Clean code" primarily means to me descriptive function names and variables, with functions that do one thing, and are not overly long.
It's stuff like not using "temp" as a variable name for "temperature" as it unnecessarily adds to the cognitive burden of understanding the code ("Does this mean temporary or temperature?")
This what I took away from the Uncle Bob book.
I expect some will latch onto the title, however, to keep with traditions, like that somehow variable names are supposed to be abbreviated.