Correlation is not causality. Swearing in the comments will not magically make your code better, but fixing a hidden bugs that you have been chasing for weeks will certainly make you swear when fixed.
> Correlation is not causality. I'm fond of pointing out, despite every time I get downvoted, that causation is the thing we have no knowledge of, and therefore correlation is all we have. As Feynman said about gravity, there is no how or why to gravity, as far as we know it's simply a property of matter. But of course, that means we only know that because of the perfect correlation between matter and gravity, includ…
Open source code with profanity in comments is statistically better
201–210 of 221 posts
Re: Open source code with profanity in comments is statistically better
#202From the research paper: > we calculate the swear factor as the number of swearwords divided by the lines of code That's what I suspected. Assuming that most swear words will be contained in comments, what this is actually measuring is the ratio of comments to code. In other words, code that is more heavily commented is better. I think we already knew this. That said I would like to see a more critical analysis. Firs…
> In other words, code that is more heavily commented is better. It could also be that understanding code in any non-trivial project is likely to back the developer into a corner where they become frustrated and swear at the computer. More importantly, the lack of swearing might be a sign that the devs lack the competence to know when they are cornered.
Re: Open source code with profanity in comments is statistically better
#203From the research paper: > we calculate the swear factor as the number of swearwords divided by the lines of code That's what I suspected. Assuming that most swear words will be contained in comments, what this is actually measuring is the ratio of comments to code. In other words, code that is more heavily commented is better. I think we already knew this. That said I would like to see a more critical analysis. Firs…
> In other words, code that is more heavily commented is better. It could also be that understanding code in any non-trivial project is likely to back the developer into a corner where they become frustrated and swear at the computer. More importantly, the lack of swearing might be a sign that the devs lack the competence to know when they are cornered.
Re: Open source code with profanity in comments is statistically better
#204Earlier quoted context omitted.
It really depends on the comments. Best practice is to comment “why” something was done, not “what” is being done, or “how”. Every programmer can read code, most code should be pretty self-explanatory. But in any sufficiently complex routine, there are going to be some things that a programmer struggled to get working the first time, that they had to work around, or that was simply unintuitive. These should be commen…
> . Best practice is to comment “why” something was done, not “what” is being done, or “how”. I disagree about the "how", at least for challenging to read sections of code. In these instances, it is not good to assume that everyone who is reading or modifying the code is an expert in the language or problem domain, so it's good to explain to them how code solves the problem. Explaining how the code works is very diff…
def group_by_interval(timestamps, interval_duration)
# do the stuff
Why does this require a comment?Re: Open source code with profanity in comments is statistically better
#205I remember reading that people who swear a lot are statistically smarter. I'm sure there are lots of caveats to that, as with the code. How long will it be before someone who doesn't understand causality starts encouraging developers to write profane comments? It wouldn't be any more absurd than lots of other non-causal behaviors I've seen pushed because somebody successful does them.
I believe Nassim Taleb wrote about this in relation to 'virtue signaling' - not swearing being a sign that people are trying to 'signal' professionalism in order to keep their jobs, and therefore are more likely to have less actual professional skills (which if good enough would secure their jobs regardless of profanity) and vice-versa. Same for hoodies over ties, etc. Although all this probably gets flipped now that…
Re: Open source code with profanity in comments is statistically better
#206Earlier quoted context omitted.
Relying on commits also fails as soon as feature branches start being squashed. And the comments in commits can’t be modified over time. You have to hope readers “git blame” the correct lines of your code. Just use comments.
Don't squash. If you insist on it, I can't imagine why you wouldn't squash the commit messages You're not supposed to change commit messages. The correct lines to blame are the ones right there, not exactly rocket science
A comment goes right there. No tools needed. Mutable. Readable. Contextually in place. And you can even add comments while coding without waiting for the commit.
Is typing // really so much effort?
Re: Open source code with profanity in comments is statistically better
#207Earlier quoted context omitted.
If the code doesn't speak for itself...
…then I would suggest altering the code to speak for itself. If you can't do that any further, refer to the 4 reasons to leave a comment.
Re: Open source code with profanity in comments is statistically better
#208Earlier quoted context omitted.
> . Best practice is to comment “why” something was done, not “what” is being done, or “how”. I disagree about the "how", at least for challenging to read sections of code. In these instances, it is not good to assume that everyone who is reading or modifying the code is an expert in the language or problem domain, so it's good to explain to them how code solves the problem. Explaining how the code works is very diff…
def group_by_interval(timestamps, interval_duration) # do the stuff Why does this require a comment?
Re: Open source code with profanity in comments is statistically better
#209Re: Open source code with profanity in comments is statistically better
#210Earlier quoted context omitted.
Don't squash. If you insist on it, I can't imagine why you wouldn't squash the commit messages You're not supposed to change commit messages. The correct lines to blame are the ones right there, not exactly rocket science
If your git squash contains all the commit messages, it’s a pain to figure out which commit message refers to which line of code. A comment goes right there . No tools needed. Mutable. Readable. Contextually in place. And you can even add comments while coding without waiting for the commit. Is typing // really so much effort?