4 ms·

And also this: - Comments are fails Sometimes you rewrite code for performance, making it fast but awful to understand. Comments are very useful in this case.

• bguthrie 13y ago
  Unless your performance optimizations specifically avoid method invocation, you can always extract the nasty bits to a well-named method. This is what is meant by comment avoidance: it is better to isolate the dirty stuff and pick good, specific names for what they do than to write an explanatory comment wherever possible.
  • mion 13y ago
    Hmm, true. But a lot of performance optimizations (and the example I had in mind) avoid method invocation. Inside a critical loop, for instance, stacking function calls can make a big difference on a dynamic language. Macros could solve this problem though.
    • mercurial 13y ago
      It's good practice to comment when necessary. Sometimes, even a "well named" method will not be expressive enough. Other times, you need to do something non-obvious (eg, work around a bug in another system). Comment when necessary. I've also found that comment tend to be both easier to maintain (due to the smaller amount of code) and more necessary (due to the higher density of information) when using more powerful languages (eg, Haskell).
• spc476 13y ago
  I tend to comment working around bugs in third party code.
  • joshka 13y ago
    Another way would be to instead wrap the third party code (and hence isolate yourself against such bugs) and use the language of choice to highlight the design decision.
    • spc476 13y ago
      But you still need to comment about why you wrapped the code in the first place.