4 ms·
Indeed - these are issues that I will be discussing, and would discuss with a candidate once I had their code in hand. I say in 2b: Each of these changes
by RiderOfGiraffes 16y ago
Indeed - these are issues that I will be discussing, and would discuss with a candidate once I had their code in hand. I say in 2b:
Each of these changes is unnecessary and in some cases
damage readability. Further, a good compiler will get
most, if not all, of the efficiency for you without
making these changes.
If changes damage readability and don't change the compiled code, don't make them!
Readability has to be balanced against efficiency, but too often people think something is more efficient when it isn't. As always, profile before "improving."
As I say, these are issues for discussion. Let me add at this point that some of the submitted versions, and some of my reference versions, are significantly different in both style and efficiency.
There is more to come.
- Groxx 16y agoI'll definitely follow along, it's been interesting. And I'd probably come up with something like the last one after a little thought, because it's pretty idiomatic of string copying. I just tend to seriously dislike code refactoring instead of algorithm refactoring, and anything that advocates it. Typically, the compiler is far better than the coder, especially when you turn on optimizations, but the compiler (nearly) can't swap out your code for a better algorithmic approach. Thus, you'd be much better off with expansive, seemingly inefficient code from a smart programmer who knows the be(st|tter) algorithm(s).