Please do not attempt to simplify this code
1–10 of 647 posts
Re: Please do not attempt to simplify this code
#2This is basically the style that rust sort of forces you to write in with allowing shorter forms where the compiler can automate checking that all error states are accounted for.
Re: Please do not attempt to simplify this code
#3The comment:code ratio is higher than anything I write or that I’ve seen.
However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality?
There are reasons why this may be the case. (More thought, more time and a large team etc)
I don’t advocate using this measure to reward anyone because it would be gamed immediately.
Re: Please do not attempt to simplify this code
#4A code style with lots of verbose if statements? Go is the perfect language!
More seriously I’ve done this style unintentionally before in JavaScript for a similar situation with plenty of branching logic. Stuff that easily could have been have the lines but not as easy to verify by hand. I’m happy to see it being formalized for certain scenarios.
Re: Please do not attempt to simplify this code
#5While I can understand the basic philosophy, it seems an unfortunate example to pick something that had 2 catastrophic failures out of 135 launches. Although, I suppose, neither of them were due to software...
Re: Please do not attempt to simplify this code
#6Porting to a language supporting exceptions would be a huge simplification. But then maybe it would stop being a space shuttle ...
Re: Please do not attempt to simplify this code
#7The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.
I think it's likely to indicate low quality. Comments are for where the code wasn't clear enough.
Re: Please do not attempt to simplify this code
#8The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.
Maybe a loose correlation? Highly commented code was probably not written under tremendous time pressure; uncommented code can go either way. Wrongly commented code is painful, though.
And then there's something I recall running into, a decade ago:
using namespace std; // using namespace standardRe: Please do not attempt to simplify this code
#9Violates title guidelines.
Re: Please do not attempt to simplify this code
#10The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.
I actually would say it’s almost the opposite, if you’re writing clean, expressive code it shouldn’t need explaining.
And if your code is clean, you shouldn’t have a bunch of redundant comments explaining the obvious.