3 ms·

What is even the downside of adding a few extra characters to the end of a comment to show who wrote it? And has Martin ever even worked on large, non-greenfie

by ziml77 5y ago

What is even the downside of adding a few extra characters to the end of a comment to show who wrote it? And has Martin ever even worked on large, non-greenfield projects? That's the only way I could see anyone professing such idealism.

jen20 5y ago
> What is even the downside of adding a few extra characters to the end of a comment to show who wrote it? You're right - in fact we should do this for every line of code, so that we know of whom to ask questions! func main() { // jen20 fmt.Println("Hello World") // ziml77 } // jen20 What's the downside of adding a few extra characters!? Of course, this view is already available to people: `git blame` - and it's the same for comments, so there is no need. The exception is "notes to future self" during the development of a feature (to be removed before review), in which case the most useful place for them to appear is at the _start_ of the comment with a marker: // TODO(jen20): also implement function X for type Y Then they are easy to find...
- ericbarrett 5y ago
  What you've shown is code clutter and reductio ad absurdum to what I wrote in the top-level comment. I am speaking of architectural comments, bug-fixes, and especially in service architecture where unusual and catastrophic interactions might happen (or have happened) with code that's not under your control.
- max46 5y ago
  >You're right - in fact we should do this for every line of code, so that we know of whom to ask questions! if you want to live in this kind of absolutism, I would rather have the name on every line than no comments at all.
  - jen20 5y ago
    Good news then: git blame already does this, and modern editors show it all the time (via copying Code Lens features from Visual Studio). Install the appropriate extension for GitHub and you can have it there too, with no extra effort or maintenance burden of duplicative metadata.

by ziml77 5y ago

jen20 5y ago

> What is even the downside of adding a few extra characters to the end of a comment to show who wrote it? You're right - in fact we should do this for every line of code, so that we know of whom to ask questions! func main() { // jen20 fmt.Println("Hello World") // ziml77 } // jen20 What's the downside of adding a few extra characters!? Of course, this view is already available to people: `git blame` - and it's the same for comments, so there is no need. The exception is "notes to future self" during the development of a feature (to be removed before review), in which case the most useful place for them to appear is at the _start_ of the comment with a marker: // TODO(jen20): also implement function X for type Y Then they are easy to find...

ericbarrett 5y ago
What you've shown is code clutter and reductio ad absurdum to what I wrote in the top-level comment. I am speaking of architectural comments, bug-fixes, and especially in service architecture where unusual and catastrophic interactions might happen (or have happened) with code that's not under your control.
max46 5y ago
>You're right - in fact we should do this for every line of code, so that we know of whom to ask questions! if you want to live in this kind of absolutism, I would rather have the name on every line than no comments at all.
- jen20 5y ago
  Good news then: git blame already does this, and modern editors show it all the time (via copying Code Lens features from Visual Studio). Install the appropriate extension for GitHub and you can have it there too, with no extra effort or maintenance burden of duplicative metadata.