3 ms·
In most cases clarity should win out over succinctness. (Sometimes succinct is more clear). I absolutely prefer the first one in almost all cases, and would pr
by jariel 6y ago
In most cases clarity should win out over succinctness. (Sometimes succinct is more clear).
I absolutely prefer the first one in almost all cases, and would probably reject the second one on a code review.
Unless we're dealing with such a core, hyper-sensitive part of the system wherein the compiler would not find rough equivalence anyhow, and the material gains from supposedly 'fewer instructions' would be better.
i.e. a pragmatic performance optimization that was realized in the real world, due to the pervasive utilization of the code ... this would be acceptable.
But for the vast majority of what we do, this won't be the case.
Double-pointers are like flame throwers - they are very 'cool' to some, and technically, they do 'burn things faster', but are just excessively dangerous and almost assuredly not the right too. Unless, they actually are, wherein you get to be the dude who uses the flamethrower, but again, that's rare.
Reading this it seems more clear to me why git has such tremendous - and mostly unnecessary UX problems. There's a dimensionality of the craft being ignored.
- souprock 6y agoThen there was the day I wrote a function that started off like this: char *fn(char **foo, char ***bar){ char *baz = *++*foo ? *foo : *++*bar; Double-pointers are just normal. The strtol function has one.
- jariel 6y agoWhile that function may have utility in some context, I would immediately assume that there's something existentially wrong with the context in which such a function was needed. Ok, it's possible the entirety of it makes sense, but given that C/C++ is full of absurd shenanigans, I think odds are something is wrong with a system that needs that kind of function in the first place. That such things are common enough doesn't make them a good practice.