←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 1 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 #
bloopernova ◴[17 Nov 24 18:45 UTC] No.42166004[source]▶
Can you recommend any refactoring tutorials or books that teach those kinds of lessons?
replies(2): >>42166079 #>>42166206 #
jprete ◴[17 Nov 24 19:09 UTC] No.42166206[source]▶
Not the GP but I think a foundational skill is naming things. If you can't give a simple name to a function/class/etc., it's probably not well-defined. It should be adjusted to make it easier to name, usually by moving responsibilities out of (or into) the code structure until it represents one concept that you can clearly state as a name.
replies(1): >>42166451 #
1. gozzoo ◴[17 Nov 24 19:37 UTC] No.42166451[source]▶
This! Coming up with meaningfull names helps you undrestand the problem and define the solution. I advise junior devs: if you don't know how to name a variable give it simple 1-letter name: a, b, x, y. When you look at the code it is immediately clear how well they understands the problem. One should be careful to avoid the naming paralasys though.