7 ms·

And when I comment code like this, I'm being needlessly verbose such that my time could be better spend doing something else. I wish more people saw comments (

• Groxx 10y ago
  yeah - I try to encourage/force coworkers to remember that while `git blame` is a fantastic and useful thing, it only tells you what, not why. It's the whys that cause the most head-scratching later, the whats are usually pretty straightforward (if not, it probably wouldn't make it through code review).
• jameshart 10y ago
  TBF, that large comment precedes 150 lines of arbitrary hex strings without even a variable name to tell them apart. I'm normally someone who prefers the code to speak to itself, rather than have a large prose comment - but if I came across that in a code review without an accompanying fifteen line comment I'd probably flag it as needing some explanation.
  • noxToken 10y ago
    Of course! Code should be concise without being cleverly brief, and it should be clear with its intentions. I write software for business though that references back to requirements. In my case, I'm not explaining a bunch of odd values that look arbitrary. I'm indicating a reason for writing something the manner I'm which I wrote, so if it needs to be modified, they're not opening 5 tabs or searching through pages of documents to make sure things are still compatible. Or worse, modifying without caring and updating the test to assertNotNull(obj).
  • baby 10y ago
    You have one comment for them. I think this is enough, unless you have no idea about what they're doing. // Signatures with special case values for r and s (such as 0 and 1). // Such values often uncover implementation errors.