4 ms·
> If programmers were paid for lines of code, copy-pasting would be best practice, and all kind of verbosity and unnecessary code or boilerplate, even dead code
by randallsquared 10y ago
> If programmers were paid for lines of code, copy-pasting would be best practice, and all kind of verbosity and unnecessary code or boilerplate, even dead code would be everywhere.
Huh. Is that what it "would be" like.
- wry_discontent 10y agoI have technical leads tell me to copy paste code all the time instead of making better abstractions. It drives me slightly mad.
- Pfhreak 10y agoI've generally followed the rule of thumb: If you're doing the same thing in two places, ok, if you are doing the same thing in three places, refactor. Let's me get away with copy pasting while I'm quickly prototyping something out, but reminds me that I need to clean it up before I try to iterate again. Plus, it's unlikely that I'll hit the right abstraction on the first or second time I see a problem. Better to wait until I've seen it three times before refactor.
- wry_discontent 10y agoI'll forget to do it if I wait until the third time. I can't keep track of everything, you know.
- ricksplat 10y agoMy worry in that case though is you could end up with a whole heap of unnecessary abstractions which can make reading by a third party (or yourself even in 6 months) a little more tricky. I'm seen so many functions of the like of `Util.checkNull(String str)` where simply `str == null || str.empty()` would have done.
- cema 10y agoI am of a different persuasion. Even if you are doing one thing, but it is indeed a thing, refactor it as a separate abstraction. You will end up with a better set of building blocks.
- ricksplat 10y ago> while I'm quickly prototyping I think any kind of skullduggery is fair game at this stage when you just want to "get it to work". For me the rule of thumb to go beyond this point is the commit (or push if I'm using git). After that point you lose control of it. Other people see it, and start to poke around and change things and retrospectively delivering on your good intentions to provide "done" code becomes more difficult. Always do a personal review before letting your code out of it's box. Of course if you can find somebody who's interested get their feedback too ...
- Roboprog 10y agoIndeed. Most "enterprise" Java code just makes my almost cry when I have to read it. WET is the order of the day. I've been doing mostly front end JS work the last year (as opposed to dabbling), and whenever I have to go back to do Java stuff again, it's really painful. But hey, we got static types, right? So we "know" our code has few if any bugs in it. (riiiiiiiight)