No post body was provided.
There’s No Such Thing as Clean Code
261–270 of 395 posts
Re: There’s No Such Thing as Clean Code
#262Wow, this post has triggered some emotion from me. I find it incredibly traumatic working with “engineers” that have this point of view. The pain individuals like this inflict on others is real! What they are really saying is that they don’t care about their fellow developers, their productivity nor happiness. This view will lead to “good enough” code that always appears to “work” but fails easily and creates more wo…
Hum... Your take from the idea that quality is multi-dimensional is that the author does not care about quality?
Re: There’s No Such Thing as Clean Code
#263Wow, this post has triggered some emotion from me. I find it incredibly traumatic working with “engineers” that have this point of view. The pain individuals like this inflict on others is real! What they are really saying is that they don’t care about their fellow developers, their productivity nor happiness. This view will lead to “good enough” code that always appears to “work” but fails easily and creates more wo…
God actually forbade me to care after 5pm.
Re: There’s No Such Thing as Clean Code
#264Earlier quoted context omitted.
The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/des…
Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I fi…
> As they say "measure twice, cut once".
and also the reuse of the term architecture.. don't put beams at random and see if it works, plan in advance and calculate. They probably had these realizations thousands of years ago, it's a generic economy principle.
I forgot what the saying is but solution unfold themselves when you thought about the problem long enough.
Oh and lastly, Grothendieck said he wasn't in the business of solving problems, but expressing them.
Re: There’s No Such Thing as Clean Code
#265Wow, this post has triggered some emotion from me. I find it incredibly traumatic working with “engineers” that have this point of view. The pain individuals like this inflict on others is real! What they are really saying is that they don’t care about their fellow developers, their productivity nor happiness. This view will lead to “good enough” code that always appears to “work” but fails easily and creates more wo…
As one of those very harmful devs you're referring to, I think you have it backwards. From my perspective, anyone who lionizes linting and arbitrary practices as "best" is actively harmful to whatever mission my team may have. Readability matters; maintainability matters; functionality matters more. The longer you talk about proper tab spacing, the less time you're talking about algorithm optimization.
If you care so much about the look of the code, you should have gone into marketing.
Re: There’s No Such Thing as Clean Code
#266No post body was provided.
Re: There’s No Such Thing as Clean Code
#267Earlier quoted context omitted.
Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front. I…
As someone who is currently over a year into rewriting a massive system with a fundamental design error by the original designer I can assure you that failing to plan your data model up front can have huge costs not just for you but for anyone who picks up your code in the future, and can hamstring a system so that it is impossible to extend or evolve.
What was the design error?
Re: There’s No Such Thing as Clean Code
#268Earlier 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"…
I agree with my whole heart. I think you forgot one of the most devastating points in Clean Code, namely short functions and DRY (when overdoing it). It leads to the same problem "jumping through 50 files". My favorite subversive action to write clean code is using jumps. There is no end to how convoluted code people write to avoid the oh so harmful leap. I feel like much of the need for short functions comes from ne…
These are the points that I've come to despise from Clean Code. After I read that book I wrote code that tried to follow all those rules. It didn't seem bad at the time, but returning to code written that way has always sucked hard. You have to jump around far too much with the 7 line function rule. And over-DRY code can actually be harder to change since repetition is often incidental. In that case a change in one place will actually affect more than its supposed to.
Re: There’s No Such Thing as Clean Code
#269Wow, this post has triggered some emotion from me. I find it incredibly traumatic working with “engineers” that have this point of view. The pain individuals like this inflict on others is real! What they are really saying is that they don’t care about their fellow developers, their productivity nor happiness. This view will lead to “good enough” code that always appears to “work” but fails easily and creates more wo…
I have emotional reaction when I see such comment.
Most unproductive and time wasting people I encountered were "clean code" and "we have to be professional" proponents.
Problem is that it was only "clean code" if it was their way and they refused to read and understand why someone else wrote something differently.
It is not bad code if you don't like it, yes it is pain to understand someone else code, yes it is pain to understand someone else article.
Re: There’s No Such Thing as Clean Code
#270The post showed me why my code is praised an understandable but I have the absolute worst time when it comes to testing it! The interfaces and abstractions needed to make a code testable is something I actively avoid in order to write code that others (including me in a few months) can glance and quickly-ish figure out what is happening and if there’s a big, where could it be. Now I can intentionally know that is a c…
Well, not lending itself to testing really is a big problem. But one does not need to sacrifice much in terms of understandability to make code testable. For instance, one does not always need an interface. You could also just inherit from the thing that you want to mock. Another problem that might be going on here is that you might be trying to test on a level that is too low. I think it is in many cases not a good…
That makes sense a lot of sense. I guess the thing is that golang and their are stdlib testing lends itself to unit testing and not so much to integration testing.
Our system also talks to a bunch of hardware via multiple protocols, for which we’d need to write simulators (so I’ve written but mostly for development and not for testing)
And apart from that, it being an async user facing gui app… well, automated testing is kind of a challenge :)
But you are right, I can think of a few things that can be tested, bigger than methods but smaller than end-to-end testing