←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 5 comments | 17 Nov 24 16:34 UTC | HN request time: 0.001s | 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 #
1. 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 #
2. leetrout ◴[17 Nov 24 18:55 UTC] No.42166079[source]▶
Not specifically this, per se, but I HIGHLY recommend "A Philosophy of Software Design" by Dr. John Ousterhout

https://web.stanford.edu/~ouster/cgi-bin/book.php

replies(1): >>42166776 #
3. 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 #
4. 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.
5. mdaniel ◴[17 Nov 24 20:12 UTC] No.42166776[source]▶
I wish I could upvote this a million times

But, I'll also point out that just like reading about exercise, merely reading the book doesn't help unless one is willing to practice and -- much, much more difficult -- get buy-in from the team. Because software engineering is usually a team sport and if one person is reading these kinds of books and trying to put them into practice, and the other members of the team are happy choosing chaos, it's going to be the outlier who gets voted off the island