141–150 of 221 posts
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…
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…
I tend to focus more on documenting the surprising code paths, not the mundane. And when my code needs to do something special because some other component (library, hardware, API) has issues, there's usually some colourful language describing the sad state of the world outside my control.
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…
I'd bet a lot of the non-profanity code is people open sourcing code just to be impressive on resumes or for school, where the profanity code is probably real code. Sounds likely to be a classic case of correlation != causation
I remember there being a startup in the Dotcom era, I forget the name but for people familiar with Cambridge, MA it was where the IDEO is now. They were notorious for a few things, but one of them was writing open source software with a lot of profanity. I thought this was cool, and was talking excitedly about it to my boss and some of the senior devs. They were less amused. Cut 20 years later and I too am less impre…
It was the most painful code review where I asked someone to remove a joke they wrote in the comments. It was a good joke, funny, short, in good taste, I loved it, but.. distracting and unnecessary.
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'd need more evidence of that. My anecdotal experience is that saying "fuck" a lot is indicative of a lack of imagination. For example, Winston Churchill's legendary devastating insults, with no profanity necessary.
Earlier quoted context omitted.
That requires everyone to have access to the repo, and to wade through it looking for changes to the relevant area of code you're working in. That sucks.
In which situation would you not have access to the repo? I guess if it's a library or something, but libraries must always be documented in a different way to business code.
Sidecars generally suck because they get lost.
Earlier quoted context omitted.
No, that is stupid. People just don't want you to write comments like // Set foo to true foo = true; Somebody saw one too many comments like that and overreacted. As long as you a) don't write comments describing what is self evident from the code, and b) try to make the code as descriptive as possible, then it's fine. Comment away.
it's not always as simple as that. what if you once implemented some facade method to get data from database like "findProductById" and you comment it with "finds a product from database by it's ID". later on, someone (maybe you) replaced some deeper logic here, so the product might be fetched from some other source, depending on some configuration. in case you didn't even touch the facade file, will you remember to…
Second, you're (I think) arguing that we shouldn't use comments because they might go out of date, which I think is throwing the baby out with the bath water.
> comments only make sense if they explain the -why-, not the -what- or -how-
That is the wrong heuristic. Comments make sense if they provide useful information that isn't self-evident from the code. Often that is the "why", but it can also be the "what" or the "how". Think about something like the fast inverse square root. A comment explaining how it works is very valuable.
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…
It is anecdata, but I can confirm this is the case for my code. I tend to focus more on documenting the surprising code paths, not the mundane. And when my code needs to do something special because some other component (library, hardware, API) has issues, there's usually some colourful language describing the sad state of the world outside my control.
Earlier quoted context omitted.
No, that is stupid. People just don't want you to write comments like // Set foo to true foo = true; Somebody saw one too many comments like that and overreacted. As long as you a) don't write comments describing what is self evident from the code, and b) try to make the code as descriptive as possible, then it's fine. Comment away.
it's not always as simple as that. what if you once implemented some facade method to get data from database like "findProductById" and you comment it with "finds a product from database by it's ID". later on, someone (maybe you) replaced some deeper logic here, so the product might be fetched from some other source, depending on some configuration. in case you didn't even touch the facade file, will you remember to…
Earlier quoted context omitted.
it's not always as simple as that. what if you once implemented some facade method to get data from database like "findProductById" and you comment it with "finds a product from database by it's ID". later on, someone (maybe you) replaced some deeper logic here, so the product might be fetched from some other source, depending on some configuration. in case you didn't even touch the facade file, will you remember to…
First of all you shouldn't comment "finds a product from database by it's ID" because that's just what the function name already says. Second, you're (I think) arguing that we shouldn't use comments because they might go out of date, which I think is throwing the baby out with the bath water. > comments only make sense if they explain the -why-, not the -what- or -how- That is the wrong heuristic. Comments make sense…