Hacker News Reader

Comment by jergason | Hacker News Reader

FWIW the comment you're calling out here is four years old: 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.

View on HN

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.

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

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

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.

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.

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.

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/94227e15eeced836b3d7b3d2b5...

Seemingly even older: https://github.com/npm/npm/commit/d519f4bd7249cc0c19baca16c3...

Reply on news.ycombinator.com