5 ms·

Why should we keep adding more complexity overhead to our languages and toolkits instead of finding people we can trust to do the job right?

dllthomas 13y ago
Because there is no one we can trust to always do the job right, and so a large code base will accumulate cruft over time. Just how carefully do you search out any possible comment referencing code you change? It's not always going to be adjacent.
- jdbernard 13y ago
  That's true, but at some point you cannot automate quality craftsmanship. Making comments part of the automated compile/test process in my opinion crosses the line and would be more detrimental than helpful. In this specific case I would prefer to add code review and emphasize practices like adjacency of comments to code. Code should be reviewed on a regular basis as well. We all make mistakes, but I think a habit of putting at least two eyes on it and of coming back periodically to review past work is better.
  - dllthomas 13y ago
    I don't pretend to know it's a good idea, and there's undoubtedly poor ways to implement it, but I think it's worth exploring. Adjacency of comments to code helps, but not everything can be adjacent to everything else, and when necessarily disparate code necessarily interacts it merits a comment that cannot be local to both. Putting multiple eyes on the code is great, but 1) isn't prevented by what I propose, 2) isn't going to be perfect (and can perhaps be done more effectively with fewer things to have to check), and 3) sometimes isn't possible (if someone is working alone, for instance). As John Carmack recently put it, on a large project "[e]verything that is syntactically legal that the compiler will accept will eventually wind up in your codebase."
    - jdbernard 13y ago
      I guess my hesitation is that I think it would probably be implemented poorly and then be forced on me by a PHB. You are right in the points you make and if it could be done so that it did not add lots of mental overhead or required boilerplate it could be a useful tool. Worth exploring, but I'll let you do the exploring. :)

dllthomas 13y ago

Because there is no one we can trust to always do the job right, and so a large code base will accumulate cruft over time. Just how carefully do you search out any possible comment referencing code you change? It's not always going to be adjacent.

jdbernard 13y ago
That's true, but at some point you cannot automate quality craftsmanship. Making comments part of the automated compile/test process in my opinion crosses the line and would be more detrimental than helpful. In this specific case I would prefer to add code review and emphasize practices like adjacency of comments to code. Code should be reviewed on a regular basis as well. We all make mistakes, but I think a habit of putting at least two eyes on it and of coming back periodically to review past work is better.
- dllthomas 13y ago
  I don't pretend to know it's a good idea, and there's undoubtedly poor ways to implement it, but I think it's worth exploring. Adjacency of comments to code helps, but not everything can be adjacent to everything else, and when necessarily disparate code necessarily interacts it merits a comment that cannot be local to both. Putting multiple eyes on the code is great, but 1) isn't prevented by what I propose, 2) isn't going to be perfect (and can perhaps be done more effectively with fewer things to have to check), and 3) sometimes isn't possible (if someone is working alone, for instance). As John Carmack recently put it, on a large project "[e]verything that is syntactically legal that the compiler will accept will eventually wind up in your codebase."
  - jdbernard 13y ago
    I guess my hesitation is that I think it would probably be implemented poorly and then be forced on me by a PHB. You are right in the points you make and if it could be done so that it did not add lots of mental overhead or required boilerplate it could be a useful tool. Worth exploring, but I'll let you do the exploring. :)