avoid repeating the same 4 lines of code twice by writing 270 lines of beautiful, abstract, generic code
@jk So when four things fail, you have to go through the 270 lines of abstract, generic code looking for the correct line to change.
As opposed to fixing it in one of the four places but forgetting the other three.
Meh. It's a subject of debate. I'd still rather have a single place to change it. 🤔
@GrahamDowns @jk eh
IME the former = an hour to fix, an hour to notice I missed something then a few minutes to find the copypasta that wasn't fixed. Maybe an hour or two if I feel like refactoring it into a function/class/whatever.
The abstract mess is hour(s) to find the part to change. Changing it, then hours more figuring out why it broke in some weird illogical way instead of fixing the problem.
@beeoproblem @jk I've had cases where it was months to find the other parts I missed. After the next release. When it was in the hands of a client, and caused a show-stopping bug for them. Because the dev who fixed it didn't know (or had long since forgotten) about the other three.
It happens. :/
@dheadshot There are always going to be minor changes in each implementation, though, to make it fit the context. Variable names, mostly. I don't know the tool you're talking about though, so I don't know if it's able to handle that. And when it comes to maintenance/enhancement/bug fixing, will I still be able to make the change in only one place and have it automatically propagate to all four places?
If so, then what you're describing is basically creating a single, generic, abstract function that you call from four different places. In which case, we have an accord. :-)
If not, then see my other replies: one of the biggest issues with duplicating code like that is that people change it in one place but don't know or forget that they need to change it in three others. The three other places maybe affect functionality that's not used very often or not used by very many clients, so it gets overlooked... until the next release, maybe months down the line, where it causes a show-stopping bug for a client and now we have to drop everything and work all-nighters to get it fixed. It's happened. @jk
It me.
@jk lol. bingo
the horrors I've seen in legacy Java enterprise codebases where it was nearly futile trying to find a section that did a real task *truly* needed by the enduser back in the real world
@jeroenvanbergen @jk lol. nice. "Like tears
.. in the rain."
"Time to kill -9"
@jk one of my ex coworker took my code, decided the bind the cli interface and the HTTP request together because they were two pair of theses. This resulted in a tight coupling, making the code hard to work with, especially for anything else than direct call to the API and left us with no client for our API so other coworker were calling the CLI, written in python, from their code, also python.
That was a factor in choosing to leave the company
Be sure to write a class to abstract integers so they can be short, long, floats or even complex in a transparent and dynamic way. And can be persisted in the cloud, database, text files or clay tablets, depending on how much time you need to keep the data.
You know you need that.
I once spent a week trying to find a bug in an obscure set of nested loops — 200+ lines of relatively obscure Cython (“for efficiency”).
Walking home one night, I realized I could replace the whole thing with a combination of matrix operations.
200 lines of buggy code turned into four lines of Numpy that
1) worked
2) was much faster than the Cython
but which felt like it required a 200 line comment explaining *why* it worked.
(Also, while writing the comment, I found the elusive bug in the original code.)
Programming tip: When Guy Steele says there’s something to be gained from learning APL, don’t wait twenty years before following up on it.
@jk Do repeat yourself!
DO. FUCKING. REPEAT YOURSELF!!
If it makes your code more robust and easier to debug, DO REPEAT YOURSELF!!!!
