Live data from Hacker News

Open source code with profanity in comments is statistically better

blog.desdelinux.net

201–210 of 221 posts

Re: Open source code with profanity in comments is statistically better

#201
post #77

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…

A reasonable working definition of causality, used by almost all scientists today, is that X causes Y if a change in X, unaccompanied by any other change, changes Y. At root, this is indeed a statement about correlations, but it's a special kind of correlation, which is hard to estimate from observational data where many other things may change along with X.

Re: Open source code with profanity in comments is statistically better

#202

From 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.

By the time you are swearing in your comments, I'm pretty sure you know you're cornered

Re: Open source code with profanity in comments is statistically better

#203

From 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.

I think anger is a sign the developer actually cares about what they are doing. In my experience, people who don't care aren't at all irritated by the imperfections of the software they have to use, they just accept it, slay their dragon and move on. People who care tend to get very angry about what's ultimately philosophical matters.

Re: Open source code with profanity in comments is statistically better

#204
post #173

Earlier 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

#205
post #20

I 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…

Do you remember where he wrote about that? Sounds like something in Antifragile, but let's be honest, any one of his books is better called a corpus.

Re: Open source code with profanity in comments is statistically better

#206
post #180

Earlier 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

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?

Re: Open source code with profanity in comments is statistically better

#207

Earlier 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.

And those meaningful relevant comments will be invisible in between those useless comments that were added to satisfy some tool that counts them.

Re: Open source code with profanity in comments is statistically better

#208
post #173

Earlier 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?

Who said require? I said it's nice to any future reader explain the algorithm if the implementation is complex. I've certainly benefited from such explanations in code.

Re: Open source code with profanity in comments is statistically better

#209
This story and the resulting discussion here on HN are such a great example of data mining with statistical methods. The researchers found a non-obvious result using statistics. Now we're all speculating about the underlying cause, trying to apply our domain knowledge to explain the result.

Re: Open source code with profanity in comments is statistically better

#210
post #180

Earlier 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?

No it's not and neither is writing a proper commit message. That's why you do both, but most of it goes in the commit. Like in the Git project
Post reply on HN