One day you will inherit a code base so bad that you’ll end up commenting old code just to make sense of it for yourself because nobody in the company has touched in a couple years and the last people that did no longer work there. It will be dangerously coupled, if you make the right change somewhere it will break everything else. It will be true spaghetti code where you spend 30 min just following a code path to figure out what and why an input into a function needs to be what it is to able to come out of another function in an exact format for anything to work.
Your so called comment standards and principals are fine if you are building something from the ground up, but the other 95% of the time, you do what you gotta do because your were blessed with a turd that is impossible to polish.
One day you will inherit a code base so bad that you’ll end up commenting old code
Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…
Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)
Your so called comment standards and principals are fine if you are building something from the ground up
Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…
One day you will inherit a code base so bad that you’ll end up commenting old code just to make sense of it for yourself because nobody in the company has touched in a couple years and the last people that did no longer work there. It will be dangerously coupled, if you make the right change somewhere it will break everything else. It will be true spaghetti code where you spend 30 min just following a code path to figure out what and why an input into a function needs to be what it is to able to come out of another function in an exact format for anything to work.
Your so called comment standards and principals are fine if you are building something from the ground up, but the other 95% of the time, you do what you gotta do because your were blessed with a turd that is impossible to polish.
Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…
Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)
Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…