3 ms·

Agree in general. > Anything that is really tightly encapsulated within a function ... well, can be a little grimy so long as it's not so bad. Point being, it'

Agree in general. > Anything that is really tightly encapsulated within a function ... well, can be a little grimy so long as it's not so bad. Point being, it's uglyless cannot spread beyond the function. Of course, if you're in the position of having to debug that function, you might curse its griminess. I tend to only write really gnarly functions if I'm trying to heavily optimize them and it is only by virtue of those optimizations that they become grimy. And even then, I tend to do it only for those functions that can easily and quickly be rewritten entirely. (And I also try to write them one optimization at a time so I can always fall back to an older, less optimized one if a bug is introduced.) And, of course, there are always comments to help light the way and warn of dragons.

jomamaxx 10y ago
Yes - but my point is, you're 'having to re-write' that function is not an existential problem for the product or company. It's just a shitty piece of work. Any individually poorly written but well encapsulated piece of shit is just a 'bathroom clean' away from being nice. Contrast that with bad design, bad APIs, or other things: they mess up other things. They can even create massive, ugly dependencies, and massively increase complexity, bugs etc. etc.. I've seen build-chains that involved 6 different scripting languages. Because we all had to use it, and almost nobody knew all 6 languages, it f*ed the whole company and caused huge pain.