I reserve comments for explaining why a section of code is needed or explaining how a complex algorithm works.
i = 0; // Set i to 0 is pointless.
if (last_output_vertex[i] == bounds[i]->length - 1) contibuting_bounds[I] = NULL; // stop outputting a bound if the entire bound has been output is helpful.
Comments can also be useful for explaining what the code is intended to do when debugging.
“Hey this function says it should return the number of apples, but looks like someone, not saying who, but someone had a brain fart and typed oranges in one variable. Who wrote this code anyway?”
I think even the second comment is not that helpful.
Just use (boolean) variables that phrase what your comment would explain, often more concise and better to read IMO. Also if the logic is more complex compose multiple named (boolean) variables. I think comments seldom make any sense at all (function doc is a one of the rare cases, mostly for the user of the library in the IDE).
I reserve comments for explaining why a section of code is needed or explaining how a complex algorithm works.
i = 0; // Set i to 0is pointless.if (last_output_vertex[i] == bounds[i]->length - 1) contibuting_bounds[I] = NULL; // stop outputting a bound if the entire bound has been outputis helpful.Comments can also be useful for explaining what the code is intended to do when debugging.
“Hey this function says it should return the number of apples, but looks like someone, not saying who, but someone had a brain fart and typed oranges in one variable. Who wrote this code anyway?”
-Last edited by JonEFive in 2021-
Past me sucks.
https://github.com/jayphelps/git-blame-someone-else/
I think even the second comment is not that helpful.
Just use (boolean) variables that phrase what your comment would explain, often more concise and better to read IMO. Also if the logic is more complex compose multiple named (boolean) variables. I think comments seldom make any sense at all (function doc is a one of the rare cases, mostly for the user of the library in the IDE).