←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 5 comments | 17 Nov 24 16:34 UTC | HN request time: 0s | source
Show context
leetrout ◴[17 Nov 24 18:05 UTC] No.42165704[source]▶
> It's better to have some wonky parameterization than it is to have multiple implementations of nearly the same thing. Improving the parameters will be easier than to consolidate four different implementations if this situation comes up again.

Hard disagree. If you cant decompose to avoid "wonky parameters" then keep them separate. Big smell is boolean flags (avoid altogether when you can) and more than one enum parameter.

IME "heavy" function signatures are always making things harder to maintain.

replies(17): >>42165868 #>>42165902 #>>42166004 #>>42166217 #>>42166363 #>>42166370 #>>42166579 #>>42166774 #>>42167282 #>>42167534 #>>42167823 #>>42168263 #>>42168489 #>>42168888 #>>42169453 #>>42169755 #>>42171152 #
fenomas ◴[18 Nov 24 01:23 UTC] No.42168888[source]▶
Hugely agree. Every junior on my team has heard me say: "copy-paste is free; abstractions are expensive." When you move two bits of logic behind a common interface you tell the world that they're the same type of thing, and future editors will tend to maintain that promise - if the two things diverge further, someone will handle that by adding more parameters to the shared interface.

So when deciding whether to merge two similar functions, to me the question to ask yourself is "are future changes to one of these functions almost certain to affect the other one as well?" If not, just leave the functions separate no matter how similar they are.

replies(2): >>42171291 #>>42174117 #
1. chambored ◴[18 Nov 24 16:41 UTC] No.42174117[source]▶
I’m only a few years in the industry, and in my CS program, we were constantly told something along the lines of “any time you have to copy paste, look for an opportunity to abstract”. I’ve been running into problems lately where my attempts at abstractions have made things significantly more complicated. Only when I hit the limits of the abstraction I realize the cost of maintaining similar functionality in multiple places was less. I’m going to try your approach in future.
replies(4): >>42174755 #>>42178106 #>>42206175 #>>42206176 #
2. nzach ◴[18 Nov 24 17:36 UTC] No.42174755[source]▶
I think the reasoning for DRY was kind of lost in translation.

“any time you have to copy paste, look for an opportunity to abstract” assumes that having an abstraction is always better, but I don't think that is the case.

In my opinion the reasoning as to why "code duplication is a code smell" is that if you have to copy and paste code around you are probably missing an useful abstraction for your code. And I think "useful" is the most important thing to keep in mind.

Sure, every time I copy and paste code I know that exist an abstraction I could create to eliminate this duplication. Generally this is pretty easy. The hard part is to understand when this new abstraction will help you to deliver the features the business need.

3. ◴[18 Nov 24 23:02 UTC] No.42178106[source]▶
4. jhanschoo ◴[21 Nov 24 16:50 UTC] No.42206175[source]▶
Surely there is a parallel with standardized testing asking the most needlessly ornate prose of its students and then most writing having more value the pialner it is written.
5. jhanschoo ◴[21 Nov 24 16:50 UTC] No.42206176[source]▶
Surely there is a parallel with standardized testing asking the most needlessly ornate prose of its students and then most writing having more value the plainer it is written.