14 ms·

> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the he

> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.

lmm 7y ago
Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.
- ZeroMinx 7y ago
  > Comments should be a last-resort stopgap I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.
- dbingham 7y ago
  Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".
  - lmm 7y ago
    > If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with. To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week. My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even if we believe senior people are more likely to be right than junior people (which I very much doubt, frankly), that tells us little about whether comments are good or not. > If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. Human programmers have a limited discipline budget, and if you're spending it on keeping the comments up to date then you're not spending it on other things. Yes, you can use manual effort to keep code explanations up to date, just as you can use manual effort to ensure that you don't use memory after it's freed, or that your code is formatted consistently, or that the tests were run before a PR is merged. But you're better off automating those things and saving your manual effort for the things that can't be automated. > And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. Disagree; code can be much more precise and clear than English, that's its great advantage. As the saying goes, the code is for humans to understand, and only incidentally for the computer to execute. The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
    - mannykannot 7y ago
      > code can be much more precise and clear than English. [my emphasis.] As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why? If you are working in something like APL, I can see there might be a case... I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.
    - gamblor956 7y ago
      code can be much more precise and clear than English Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.
- kochthesecond 7y ago
  I'm 29 and can barely remember the code I wrote last week. Comments don't get updated when the requirements for the code change, more often than not end up as misleading. The only thing worth commenting are actual libraries that are maintained, and 'magic values'.
- chrshawkes 7y ago
  All those comments of "blah blah blah gets or sets a value" on my class properties, why do we add all that overhead to our projects to the point we have to use tools like GhostDoc to write our worthless comments? This industry is on crack sometimes. I simply like comments for adding things like... so and so told me to do this... or simply documenting weird behavior or weird business logic.
- war1025 7y ago
  Comments and `git log -p <file>` to see what the comment originally referred to is pretty useful. My personal favorite comment style is to wrap a chunk of code in `#{` `#}` blocks and add a general comment of what that chunk of code is accomplishing. Sort of like an inline method.
- mannykannot 7y ago
  Nothing enforces that the code is correct, either, not even tests, as tests are also code, plus there is the utter infeasibility of exhaustive testing. It does not follow from the possibility for error that a "significant" proportion of comments will necessarily be false. In my experience, that is most likely when an organization has commenting as a mandatory part of its process, which inevitably leads to most comments being trite, and some wrong. Outside of that, comments have not been a problem mainly because they are almost non-existent, even when the code could benefit from them.
- esoterica 7y ago
  Nothing enforces correct variable names and descriptive types either, why would you expect those to be more consistently accurate than comments?
  - lmm 7y ago
    They're amenable to automated refactoring, and if you change a type or variable name in one place you're forced to update it everywhere else that uses the same thing.
- JamesBarney 7y ago
  Comments rot, but so does everything else such as type names, tests, variable names, field names, designs, architectures, etc.
  - marvin 7y ago
    Yep - it doesn't help much with a method that's named EmptyCacheToPreventBlugblagCongestion() if external circumstances have stopped the blugblag from ever congesting any longer. So discipline in maintaining the intent of the code is required even if you never write a single comment.
  - lmm 7y ago
    Tests, types and field names get checked on build.
    - JamesBarney 7y ago
      If someone adds functionality to a type so the name isn't really applicable anymore I don't think the build catches that.
      - lmm 7y ago
        As soon as you form something that should conform to the type (according to its name) and find that it doesn't, you notice the problem, and then you fix it once and for all (because the type is defined in one place). So yes, you can have misleading type names in the codebase, but there's a natural pressure to correct them, in a way that there largely isn't for misleading comments.
- njharman 7y ago
  (as others have pointed out here and every where) Comments are NOT for making code understandable. The things you mentioned are for that. Comments are for things like 1) explaining why this thing that looks wrong or dumb, really isn't. 2) explaining what method/function/class/whatever is suppose to do. Because code can be correct, understandable, and still wrong.
crankylinuxuser 7y ago
Thats also a reason I will include as a comment the unoptimized code with comments whenever I do optimized crazycode. That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization. But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....
- CuriouslyC 7y ago
  Did you mean N*logN? I don't think going to N^logN is what you want ;)
  - crankylinuxuser 7y ago
    Sigh, yep! Thats what I get for trying to type it on a phone browser!
CuriouslyC 7y ago
Comments rot, and details about what is going on is better incorporated using good variable names and functions that abstract aspects of a task from their implementation. While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things that need to be addressed in the future.
- deleted 7y ago
  [deleted]
- macintux 7y ago
  Comments are critical for explaining the code that isn’t there. False starts, obvious optimizations that don’t actually work, etc.
- bg4 7y ago
  I think it's better to document the context/intention/business reasons and let the code speak for itself.
- gamblor956 7y ago
  I've heard these sentiments very frequently from junior programmers, and almost never from senior programmers.
  - CuriouslyC 7y ago
    I'm guessing most of the senior programmers you've interacted with are maintaining established software with low churn and high availability requirements. I hear comment love very frequently from enterprise engineers working with 10+ year old Java codebases, but very infrequently from hackers working with young code bases in more concise languages (complex algorithms aside).
  - ohaideredevs 7y ago
    Complete opposite for me.
- 7y ago
drbojingle 7y ago
There's truth to both sides. Depends on the comment really. ``` doesAThing() //does a thing ``` doesn't help anyone. My rule: Code is for how, comment is for why.
- TimTheTinker 7y ago
  > Code is for how, comment is for why. Excellent. For interfaces, other code that uses the interface (perhaps even tests) can also help to document the "why".
ben509 7y ago
Also related: > Understood as senior: Communication skills matter most. The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments. Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing." Yes, those are pointless. Often what's going on is a person is dumping their stream of consciousness into the comment field. It takes practice to understand what a reader needs to know. You have to actually practice reading comments and thinking things through (another reason code review is important in your team) to get good at undertanding what you should write down. All that said, if you truly hate commenting, at least build a habit of descriptive naming and exploiting your type system as fully as possible.
- beat 7y ago
  I'm actually thinking more of social skills and written language, not programming. I said something about this in a different thread earlier this week, and someone was baffled as to why I thought being able to write and sell was important, since you just wind up doing what your boss tells you to do anyway. As opposed to telling the boss what you're going to do.
- mads_ravn 7y ago
  > Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing." I actually think those comments are useful in two ways: 1. The process of writing a comment will help often help me rename the function/variables so e.g. “defines a function that opens thing” becomes something like “opens can_of_worms with the given instrument and restraints” for the method definition open_can_of_worms(instrument, restraints) 2. You can use variable/return value comments to further restrict the domain of values, e.g. non-null, positive or in the range 1-42 (arguably it would be better to express some of these in the type system, but that is a different discussion). These comments show up in my IDE when I try to call the code in a remote location, so I don’t have to guess or remember the constraints. (edit formatting)
mbreese 7y ago
> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. I couldn't agree more. A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code. In addition to comments (particularly around hard to grok code), I've also started trying to be as consistent as possible in code structure and naming schemes. This also helps a lot.
- Gibbon1 7y ago
  I write notes to my future self all the time. Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank. Meta comment2: I don't think the code needs to do this here. But I can't prove it right now. Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production. Meta comment4: This function name isn't correct. But I can't think of a name that is better.
  - xsmasher 7y ago
    > Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production. This is the highest purpose that a comment can fulfill - telling why you are doing something that looks stupid.
  - polyterative 7y ago
    > This function name isn't correct When dealing with articulate code I often rename the same thing multiple time while I understand it better/clarify it's purpose. Also I love how naming protects the purpose of a variable or method, mentally speaking
  - vharuck 7y ago
    > Meta comment: This is bullshit I used to worry about putting emotional blurbs in comments or commit messages, but I'm starting to see their value. A commit that starts "This ugly writing is to appease Roger, the editor obsessed with AP style" lets me know three things: - Who asked for the change - The source of the content - The fact I disagree but still do it, so future me doesn't pick fights present me avoided Of course, it could also mean "TODO: revert this commit the minute Roger retires."
jschwartzi 7y ago
Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you didn't break anything. Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.
- camtarn 7y ago
  Line numbers might not stay static. Perhaps referring to a particular function or variable might be better, as well as explaining what it might impact? That way, one can jump to the location, then inspect it to see if the potentially-impacting behaviour still exists. Definitely useful in the case where it's near-to-impossible to DRY up something, though. Sadly, the limitations of an industrial C environment have led my code to contain a lot of annoying 'If you add something here, make sure to add it to X struct and Y function' comments.
- HeyLaughingBoy 7y ago
  This is especially problematic in machine-control code. I've seen code from an otherwise highly capable developer that contained 1000+ LOC functions. When asked why he couldn't do a refactor the answer boiled down to fear. When the only real way to test the code is by physically running a machine through a number of scenarios, many of which are difficult at best to recreate, you become very reluctant to refactor or clean it up. Like all problems, it's best to nip it in the bud before things get that far out of line.
darepublic 7y ago
As I've matured as a developer I generally find it easier to read and understand code, whether it be my own or others. As a junior this is something I definitely struggled with.

lmm 7y ago

Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.

ZeroMinx 7y ago
> Comments should be a last-resort stopgap I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.
dbingham 7y ago
Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".
- lmm 7y ago
  > If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with. To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week. My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even if we believe senior people are more likely to be right than junior people (which I very much doubt, frankly), that tells us little about whether comments are good or not. > If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. Human programmers have a limited discipline budget, and if you're spending it on keeping the comments up to date then you're not spending it on other things. Yes, you can use manual effort to keep code explanations up to date, just as you can use manual effort to ensure that you don't use memory after it's freed, or that your code is formatted consistently, or that the tests were run before a PR is merged. But you're better off automating those things and saving your manual effort for the things that can't be automated. > And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. Disagree; code can be much more precise and clear than English, that's its great advantage. As the saying goes, the code is for humans to understand, and only incidentally for the computer to execute. The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
  - mannykannot 7y ago
    > code can be much more precise and clear than English. [my emphasis.] As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why? If you are working in something like APL, I can see there might be a case... I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.
  - gamblor956 7y ago
    code can be much more precise and clear than English Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.
kochthesecond 7y ago
I'm 29 and can barely remember the code I wrote last week. Comments don't get updated when the requirements for the code change, more often than not end up as misleading. The only thing worth commenting are actual libraries that are maintained, and 'magic values'.
chrshawkes 7y ago
All those comments of "blah blah blah gets or sets a value" on my class properties, why do we add all that overhead to our projects to the point we have to use tools like GhostDoc to write our worthless comments? This industry is on crack sometimes. I simply like comments for adding things like... so and so told me to do this... or simply documenting weird behavior or weird business logic.
war1025 7y ago
Comments and `git log -p <file>` to see what the comment originally referred to is pretty useful. My personal favorite comment style is to wrap a chunk of code in `#{` `#}` blocks and add a general comment of what that chunk of code is accomplishing. Sort of like an inline method.
mannykannot 7y ago
Nothing enforces that the code is correct, either, not even tests, as tests are also code, plus there is the utter infeasibility of exhaustive testing. It does not follow from the possibility for error that a "significant" proportion of comments will necessarily be false. In my experience, that is most likely when an organization has commenting as a mandatory part of its process, which inevitably leads to most comments being trite, and some wrong. Outside of that, comments have not been a problem mainly because they are almost non-existent, even when the code could benefit from them.
esoterica 7y ago
Nothing enforces correct variable names and descriptive types either, why would you expect those to be more consistently accurate than comments?
- lmm 7y ago
  They're amenable to automated refactoring, and if you change a type or variable name in one place you're forced to update it everywhere else that uses the same thing.
JamesBarney 7y ago
Comments rot, but so does everything else such as type names, tests, variable names, field names, designs, architectures, etc.
- marvin 7y ago
  Yep - it doesn't help much with a method that's named EmptyCacheToPreventBlugblagCongestion() if external circumstances have stopped the blugblag from ever congesting any longer. So discipline in maintaining the intent of the code is required even if you never write a single comment.
- lmm 7y ago
  Tests, types and field names get checked on build.
  - JamesBarney 7y ago
    If someone adds functionality to a type so the name isn't really applicable anymore I don't think the build catches that.
    - lmm 7y ago
      As soon as you form something that should conform to the type (according to its name) and find that it doesn't, you notice the problem, and then you fix it once and for all (because the type is defined in one place). So yes, you can have misleading type names in the codebase, but there's a natural pressure to correct them, in a way that there largely isn't for misleading comments.
njharman 7y ago
(as others have pointed out here and every where) Comments are NOT for making code understandable. The things you mentioned are for that. Comments are for things like 1) explaining why this thing that looks wrong or dumb, really isn't. 2) explaining what method/function/class/whatever is suppose to do. Because code can be correct, understandable, and still wrong.

crankylinuxuser 7y ago

Thats also a reason I will include as a comment the unoptimized code with comments whenever I do optimized crazycode. That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization. But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....

CuriouslyC 7y ago
Did you mean N*logN? I don't think going to N^logN is what you want ;)
- crankylinuxuser 7y ago
  Sigh, yep! Thats what I get for trying to type it on a phone browser!

CuriouslyC 7y ago

Comments rot, and details about what is going on is better incorporated using good variable names and functions that abstract aspects of a task from their implementation. While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things that need to be addressed in the future.

deleted 7y ago
[deleted]
macintux 7y ago
Comments are critical for explaining the code that isn’t there. False starts, obvious optimizations that don’t actually work, etc.
bg4 7y ago
I think it's better to document the context/intention/business reasons and let the code speak for itself.
gamblor956 7y ago
I've heard these sentiments very frequently from junior programmers, and almost never from senior programmers.
- CuriouslyC 7y ago
  I'm guessing most of the senior programmers you've interacted with are maintaining established software with low churn and high availability requirements. I hear comment love very frequently from enterprise engineers working with 10+ year old Java codebases, but very infrequently from hackers working with young code bases in more concise languages (complex algorithms aside).
- ohaideredevs 7y ago
  Complete opposite for me.
7y ago

drbojingle 7y ago

There's truth to both sides. Depends on the comment really. ``` doesAThing() //does a thing ``` doesn't help anyone. My rule: Code is for how, comment is for why.

TimTheTinker 7y ago
> Code is for how, comment is for why. Excellent. For interfaces, other code that uses the interface (perhaps even tests) can also help to document the "why".

ben509 7y ago

Also related: > Understood as senior: Communication skills matter most. The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments. Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing." Yes, those are pointless. Often what's going on is a person is dumping their stream of consciousness into the comment field. It takes practice to understand what a reader needs to know. You have to actually practice reading comments and thinking things through (another reason code review is important in your team) to get good at undertanding what you should write down. All that said, if you truly hate commenting, at least build a habit of descriptive naming and exploiting your type system as fully as possible.

beat 7y ago
I'm actually thinking more of social skills and written language, not programming. I said something about this in a different thread earlier this week, and someone was baffled as to why I thought being able to write and sell was important, since you just wind up doing what your boss tells you to do anyway. As opposed to telling the boss what you're going to do.
mads_ravn 7y ago
> Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing." I actually think those comments are useful in two ways: 1. The process of writing a comment will help often help me rename the function/variables so e.g. “defines a function that opens thing” becomes something like “opens can_of_worms with the given instrument and restraints” for the method definition open_can_of_worms(instrument, restraints) 2. You can use variable/return value comments to further restrict the domain of values, e.g. non-null, positive or in the range 1-42 (arguably it would be better to express some of these in the type system, but that is a different discussion). These comments show up in my IDE when I try to call the code in a remote location, so I don’t have to guess or remember the constraints. (edit formatting)

mbreese 7y ago

> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. I couldn't agree more. A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code. In addition to comments (particularly around hard to grok code), I've also started trying to be as consistent as possible in code structure and naming schemes. This also helps a lot.

Gibbon1 7y ago
I write notes to my future self all the time. Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank. Meta comment2: I don't think the code needs to do this here. But I can't prove it right now. Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production. Meta comment4: This function name isn't correct. But I can't think of a name that is better.
- xsmasher 7y ago
  > Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production. This is the highest purpose that a comment can fulfill - telling why you are doing something that looks stupid.
- polyterative 7y ago
  > This function name isn't correct When dealing with articulate code I often rename the same thing multiple time while I understand it better/clarify it's purpose. Also I love how naming protects the purpose of a variable or method, mentally speaking
- vharuck 7y ago
  > Meta comment: This is bullshit I used to worry about putting emotional blurbs in comments or commit messages, but I'm starting to see their value. A commit that starts "This ugly writing is to appease Roger, the editor obsessed with AP style" lets me know three things: - Who asked for the change - The source of the content - The fact I disagree but still do it, so future me doesn't pick fights present me avoided Of course, it could also mean "TODO: revert this commit the minute Roger retires."

jschwartzi 7y ago

Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you didn't break anything. Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.

camtarn 7y ago
Line numbers might not stay static. Perhaps referring to a particular function or variable might be better, as well as explaining what it might impact? That way, one can jump to the location, then inspect it to see if the potentially-impacting behaviour still exists. Definitely useful in the case where it's near-to-impossible to DRY up something, though. Sadly, the limitations of an industrial C environment have led my code to contain a lot of annoying 'If you add something here, make sure to add it to X struct and Y function' comments.
HeyLaughingBoy 7y ago
This is especially problematic in machine-control code. I've seen code from an otherwise highly capable developer that contained 1000+ LOC functions. When asked why he couldn't do a refactor the answer boiled down to fear. When the only real way to test the code is by physically running a machine through a number of scenarios, many of which are difficult at best to recreate, you become very reluctant to refactor or clean it up. Like all problems, it's best to nip it in the bud before things get that far out of line.

darepublic 7y ago

As I've matured as a developer I generally find it easier to read and understand code, whether it be my own or others. As a junior this is something I definitely struggled with.