I know this is style-consistent (see 5 lines up) but FWIW, I really think that function descriptions should go on the line above the function declaration, not inside it.

IMHO, for this PR we should keep it file-wide consistent and not change too much about non-PR-related issues like style etc.
This would IMHO only mess up the diff possibly needed for later corrections (fingers crossed)

Yep, I was ok with it, that's why I approved the PR overall during this pass.

Sorry if that was unclear—I meant that more as an aside. I like keeping up discussion about style/clarity even though we have no fixed standards in place.

:)

https://medium.freecodecamp.com/the-100-correct-coding-style-guide-5b594a1655f0

I don't appreciate this response. I feel like I get called a pedant every time I suggest a style change.

I'm sorry, my response was not meant to be personal. I just like the conclusion the author makes:

When it comes to coding standards, I take what I get and I don’t get upset.

If you happen to find yourself in a position to pick your own style guide, I recommend that you ask yourself these two simple questions:

• Is there tooling that will automatically apply the style rules to my code with little to no intervention from me?
• Are the tools and underlying styles actively maintained and/or used by reputable organizations?

If you can answer “yes” to both of those questions, then you’re good to go. Simple as that.

IMHO, we should not nitpick (edit: this is just my very personal wording here, did not read your comment in the other request... I hope you get my idea and general positiveness :) ) within PRs (and I explicitely include myself here) but rather concentrate on getting them closed within the current standards. If there turns out to be a need for different guideline/adjustments to guidelines, we should start a separate discussion about them.

Ok. I would much rather have appreciated this response than posting an article link without comment, which made me feel like I was being dismissed even though you may have intended an entirely different effect. Something I've learned over the last few weeks is that it's healthier to actively redirect conversations than to shut them down or passively defer them. The reason I brought this up here is because we have no precedent for starting or maintaining these conversations. So, it is easy to take a request that we "discuss this somewhere else" as a similar kind of dismissal. But obviously, our conversation about my initial comment has generated a significant amount of noise on this PR, so your point is well-taken! Maybe we'll have a chance to discuss this on Saturday. :)

My two cents: We're volunteers. If style is too strict, eventually we will have fewer volunteers. If style is too loose, the codebase becomes a mess. Somewhere in there is the middle way. Noting the position of a comment seems some distance away from that middle, to me at least.

I realize it's a touchy subject, and it makes my flesh crawl when another developer puts spaces near parens or brackets when I wouldn't, or doesn't put spaces near braces when I would, or... or... ... but... we're volunteers.

^ this is the problem though, that everyone has a different idea of what's OK to compromise on, and what isn't. For instance, in this PR, I was more than happy to compromise and let this topic go. But in the larger scheme, I think it does make the codebase messy and significantly more difficult to read, and I would push for it to be changed.

While I was reviewing this, I spent at least a couple seconds reading comments that I wouldn't have read otherwise because they looked like they signalled something unusual about the function body, rather than harmlessly describing the function itself. Like almost everyone else (see this thread for instance), and like most code documentation schemes (Javadoc, Rustdoc, Doxygen, etc.), I am conditioned to expect comments to apply to the code below, or the the statement to the left, and not the code above. So, it was difficult to read because, even though nothing was amiss, I had to read the comment, understand that it was descriptive, and then continue on to the next function body, in the same time that I could have scanned multiple visually similar function blocks. It was distracting, and not just because I wanted to correct it :)

Unlike spacing around parens, putting a comment in the wrong place breaks semantic flow of the document and also introduces the potential for confusion. That's why I'd consider it a step higher in importance.

I'm aware that this sounds myopic out of context, but I just want to lay out very cleanly and clearly why I made my initial comment.

trailing space on these two lines

trailing space on the three lines above