24 ms·

FWIW the comment you're calling out here is four years old: https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a697a04fea77d8e6/lib/config/core.js#L153 ht

FWIW the comment you're calling out here is four years old: https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a697a04fea77d8e6/lib/config/core.js#L153 https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a69..., before npm inc was formed. The correctMkdir change seems more recent, but not really related to that specific comment.

zdragnar 9y ago
This could be my inner grumpy old man speaking, but as a general rule of thumb, I look very poorly on editorializing in code comments. Originally because I didn't want my junior devs embarrassing the company when our clients received control of the code we wrote, but that also transferred into my perception of open source. That comment should not have survived 4 years. Again, inner grumpy old man showing through. Edit: to be clear, such comments are treated as reflective of the people and organization behind them.
- lucideer 9y ago
  I think there should definitely be limits to this—some brevity/levity can be positive—so I would always try to err on the side of acceptance, but in general I agree. In this particular case at least, this comment seems to betray some hint of an anti-user sentiment.
  - zdragnar 9y ago
    An appropriate limit is, as I mentioned, editorializing. To be precise, your clients, peers and users should not the the target of your feelings expressed in comments. An additional litmus should be professional discipline: express dissatisfaction with a todo (ideally referencing a bug or discussion issue source URL or identifier). Without that reference, it acknowledges an issue without indicating any motivation to solve or re-mediate the original cause, which is (IMHO) indicative of a careless and lazy attitude.
- predakanga 9y ago
  I can see your point (particularly with regard to deliverables), but I suspect the practice is quite widespread - comments often end up being used as a sort of brain dump. For instance, see this article (from 2004) on comments in the Win2k source code: http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html
  - zdragnar 9y ago
    That's a fair enough point, especially when directly employed working on closed source / proprietary code. You're essentially stuck in an echo chamber, and professional standards are more difficult to maintain when you don't have the whole of the world looking on. I also imagine that the mental strain of figuring out edge cases and poor documentation in a system as complex as a windows OS would be enough to make anyone at least a little salty. However widespread it may be, that does not me that I have to like it :D
- Piskvorrr 9y ago
  I think it's even more harmful: "there's the comment that code does X, so the code does X" (or in this case, an implicit hint that the code fixes non-X) - in other words, wishful thinking.
lucideer 9y ago
Ah, yeah, you're right. I was looking at it in diff[0] and hadn't noticed it lost context. With the full comment, it seems they're instead bemoaning having to adhere to a user's config. Not sure which is worse... [0] https://github.com/npm/npm/commit/94227e15eeced836b3d7b3d2b5e5cc41d4959cff https://github.com/npm/npm/commit/94227e15eeced836b3d7b3d2b5...
plopz 9y ago
Seemingly even older: https://github.com/npm/npm/commit/d519f4bd7249cc0c19baca16c3b6c830413a38c8#diff-0274417318d45b56e7adc8820b6a76b3R101 https://github.com/npm/npm/commit/d519f4bd7249cc0c19baca16c3...

zdragnar 9y ago

This could be my inner grumpy old man speaking, but as a general rule of thumb, I look very poorly on editorializing in code comments. Originally because I didn't want my junior devs embarrassing the company when our clients received control of the code we wrote, but that also transferred into my perception of open source. That comment should not have survived 4 years. Again, inner grumpy old man showing through. Edit: to be clear, such comments are treated as reflective of the people and organization behind them.

lucideer 9y ago
I think there should definitely be limits to this—some brevity/levity can be positive—so I would always try to err on the side of acceptance, but in general I agree. In this particular case at least, this comment seems to betray some hint of an anti-user sentiment.
- zdragnar 9y ago
  An appropriate limit is, as I mentioned, editorializing. To be precise, your clients, peers and users should not the the target of your feelings expressed in comments. An additional litmus should be professional discipline: express dissatisfaction with a todo (ideally referencing a bug or discussion issue source URL or identifier). Without that reference, it acknowledges an issue without indicating any motivation to solve or re-mediate the original cause, which is (IMHO) indicative of a careless and lazy attitude.
predakanga 9y ago
I can see your point (particularly with regard to deliverables), but I suspect the practice is quite widespread - comments often end up being used as a sort of brain dump. For instance, see this article (from 2004) on comments in the Win2k source code: http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html
- zdragnar 9y ago
  That's a fair enough point, especially when directly employed working on closed source / proprietary code. You're essentially stuck in an echo chamber, and professional standards are more difficult to maintain when you don't have the whole of the world looking on. I also imagine that the mental strain of figuring out edge cases and poor documentation in a system as complex as a windows OS would be enough to make anyone at least a little salty. However widespread it may be, that does not me that I have to like it :D
Piskvorrr 9y ago
I think it's even more harmful: "there's the comment that code does X, so the code does X" (or in this case, an implicit hint that the code fixes non-X) - in other words, wishful thinking.

lucideer 9y ago

Ah, yeah, you're right. I was looking at it in diff[0] and hadn't noticed it lost context. With the full comment, it seems they're instead bemoaning having to adhere to a user's config. Not sure which is worse... [0] https://github.com/npm/npm/commit/94227e15eeced836b3d7b3d2b5e5cc41d4959cff https://github.com/npm/npm/commit/94227e15eeced836b3d7b3d2b5...

plopz 9y ago

Seemingly even older: https://github.com/npm/npm/commit/d519f4bd7249cc0c19baca16c3b6c830413a38c8#diff-0274417318d45b56e7adc8820b6a76b3R101 https://github.com/npm/npm/commit/d519f4bd7249cc0c19baca16c3...