I didn't follow Terry at all, but some of his archived videos contained some pretty agreeable philosophical positions. Neither do I follow John Carmack but I rather like this line:
If you're willing to restrict the flexibility of your approach, you can almost always do something better.
IMO strictly idiomatic, garden-variety, very verbose C often found on Codewars is just another kind of premature optimization: optimizing for "maintenance"... and aggressively promoting bloat. As opposed to the classic sense, when you don't already know where your code spends the most time, optimizing for refactoring is always premature because you never know what will need to change if the requirements change. This is just my relatively recent conclusion. Sure, people also optimize for readability, but I think that's mostly for the basic assumptions of maintenance & the current 'industry' status quo... which is broken anyway.
To be fair and honest, a lot of my solutions are what you said, tangled messes of expressions, usually just so I can avoid using curly braces as often as possible and try for minimal LOC. Sometimes things get ugly.
Also, to be fair and honest, I never studied / compared the assembly output, and I should.
I'm sorry, when I asked about 'others' I meant other collections of hacks or snippets with links that you could share. No, I don't know lots of these things, and I've only ever needed 2 or 3 of the hacks in that collection.
That double move is pretty sick. Someone may have had nightmares...
I'm with you. It seems like "maintainability" is a curse; it apparently means, "we promise that thing that works will eventually stop working, so make it both verbose and with lower density, easier to refactor it rather than rewrite or replace it" ...at the cost of it being fairly well-tuned for its original purpose.
Of course you don't get to do such things when the enum isn't ordered so conveniently as it was here. And of course, treating it as "just an int" also makes things less self-documenting and more brittle. But hey, this isn't a codebase.
Merged.
Would you mind your language a bit.
see also: A tale of two libcs
The author understands C well enough, I think. Some associated Internet drama is unfortunate.
I didn't follow Terry at all, but some of his archived videos contained some pretty agreeable philosophical positions. Neither do I follow John Carmack but I rather like this line:
IMO strictly idiomatic, garden-variety, very verbose C often found on Codewars is just another kind of premature optimization: optimizing for "maintenance"... and aggressively promoting bloat. As opposed to the classic sense, when you don't already know where your code spends the most time, optimizing for refactoring is always premature because you never know what will need to change if the requirements change. This is just my relatively recent conclusion. Sure, people also optimize for readability, but I think that's mostly for the basic assumptions of maintenance & the current 'industry' status quo... which is broken anyway.
To be fair and honest, a lot of my solutions are what you said, tangled messes of expressions, usually just so I can avoid using curly braces as often as possible and try for minimal LOC. Sometimes things get ugly.
Also, to be fair and honest, I never studied / compared the assembly output, and I should.
I'm sorry, when I asked about 'others' I meant other collections of hacks or snippets with links that you could share. No, I don't know lots of these things, and I've only ever needed 2 or 3 of the hacks in that collection.
That
doublemove is pretty sick. Someone may have had nightmares...I'm with you. It seems like "maintainability" is a curse; it apparently means, "we promise that thing that works will eventually stop working, so make it both verbose and with lower density, easier to refactor it rather than rewrite or replace it" ...at the cost of it being fairly well-tuned for its original purpose.
Do you know of any others like Bit Twiddling Hacks?
Of course you don't get to do such things when the enum isn't ordered so conveniently as it was here. And of course, treating it as "just an int" also makes things less self-documenting and more brittle. But hey, this isn't a codebase.
Hi, I replied on email 😉
removed
constqualifiercan you provide a test case that this solution would fail ? ;-)