> Goodbye, Clean Code You mean like with the invention of the abstraction/hack called hooks?
Care to share the shortcomings of hooks?
Goodbye, Clean Code
271–280 of 599 posts
Re: Goodbye, Clean Code
#272Earlier quoted context omitted.
One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good. On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.
Tests rarely have bugs, I find, so generally dry isn’t critical. Also, dry is for security (see below)
Tests are there to catch issues. In a way, almost every bug that makes it to production is a test bug.
Not to mention the inconsistent tests that fail so randomly from timing issues that the team ignores them
Re: Goodbye, Clean Code
#273I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…
When you work with your own apps you can be as messy as you like. In a team there is some incentive to make the code readable to other developers. At the lightweight end you have coding standards and linting, then design patterns then finally big refactorings. It’s all trade offs. Bug team products can have islands of code that are like one person projects and those can be messy for example.
Re: Goodbye, Clean Code
#274> 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. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together.
I totally disagree one million percent! If you are on my team and you want to rewrite code I wrote (cause it sux) then do it! Don't ask, just DO IT! DO IT NOW! Have a blast, tear it apart, rewrite all my shitty abstractions and see if you can do it better. If the result is better code, then awesome! I learn something and the software gets better. If the result is worse code, then awesome! I'll tell you why, you'll learn something and your improved understanding will allow you to write better code.
I also think that a salaried engineer who thinks that a piece of code he or she (but almost always he) wrote is "his" or "hers" is totally wrong. It's the company's code. Having a false sense of ownership towards that code will just cause grief for that engineer and friction for his or her team.
Re: Goodbye, Clean Code
#275I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…
I find that every 1000 lines of code I write, my productivity goes down a bit more. Without refactoring, my code just gets really coupled and it gets harder to change. Your position is that the time cost of refactoring is less than that of speed up benefits?
Re: Goodbye, Clean Code
#276Earlier quoted context omitted.
That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…
The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…
The rule of 3 usually is in reference to small scoped abstractions, not whole modules or subsystems. We're talking about extracting a short function, not significant and potentially thorny chunks of code.
But I guess no one explicitly spells this out, so I could see where someone could become confused.
Re: Goodbye, Clean Code
#277Earlier quoted context omitted.
Wasn't it the case that the requirements were the same at the time the code was written? TextBlock.resizeTopLeft(...) and Rectangle.resizeTopLeft(...) did the same thing for the same reason, not by coincidence. The issue was the possiblity (and eventually the reality) of future divergence.
I disagree. If they had separate classes for TextBlock and Rectangle, then likely there are separate requirements involved. It may have been that at the time they needed separate classes the requirements for resizeTopLeft was identical, but they are still two separate requirements . I suggest everyone take a minicourse or read a book on systems engineering - at least the part where they discuss requirements. The fact…
> I suggest everyone take a minicourse or read a book on systems engineering - at least the part where they discuss requirements. The fact that two distinct entities have an identical requirement for something does not mean there is one requirement. It means there are two requirements which (for now) happen to be identical.
I'd love to do this -- do you have any recommendations for a book like this?
Re: Goodbye, Clean Code
#278What the author described in the article is where ORMs come from.
And why they don’t work. In the words of the great Jeff Goldblum: https://youtu.be/6GEFwiXWieM
Re: Goodbye, Clean Code
#279I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…
the rule is "do the simplest thing that could possibly work"
Re: Goodbye, Clean Code
#280> 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. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…
If you are on my team and you want to rewrite code I wrote (cause it sux) then do it!
Sure, rewriting is fine, but ideally it would come in the form of a PR rather than being checked in, so if you had valid reasons for writing it that way, it can be reverted before anyone else layers code on top of the bad rewrite.