4 ms·

a comment on items 4 and 6: whilst I totally agree with it, from my experience, many programmers decide in advance what might be used in a more generic sense, a

a comment on items 4 and 6: whilst I totally agree with it, from my experience, many programmers decide in advance what might be used in a more generic sense, and end up generalizing code that is effectively used once or twice. This means in some cases that instead of reading one function to understand what's going on, you have to jump through several files to understand the whole thing... My personal rule of thumb is that if some pattern repeats 3 times or more, I would consider it boilerplate, and refactor it into a separate library/function. Before that, it's not enough to make a 'rule' out of one or two occurrences.

tempestn 14y ago
Very much agree with this. It seems like a sort of analysis paralysis that specifically affects some programmers. Reminds me of a HN post a while back actually by someone who was passionate about building games, but ended up generalizing into building game engine tools, then graphical tools, etc., eventually spending years building ever more general tools, without making any real progress toward his true goal. You can write your code with modularity in mind, without necessarily having to completely decouple and generalize everything. Once it becomes sufficiently beneficial for a particular module, the refactoring then shouldn't be too onerous. (Regardless, this 'beautiful code checklist' is fantastic.)