[HN Gopher] Open source code with profanity in comments is stati...
___________________________________________________________________
Open source code with profanity in comments is statistically better
Author : dev_snd
Score : 205 points
Date : 2023-07-04 09:58 UTC (2 days ago)
(HTM) web link (blog.desdelinux.net)
(TXT) w3m dump (blog.desdelinux.net)
| saintradon wrote:
| Isn't there a study that shows that people can tolerate pain
| better when they swear? This doesn't really surprise me. I'll
| swear in my code if I really feel like it but commits and
| everything else I keep more presentable.
| pyeri wrote:
| It's just that you've evolved biological filters that "block"
| the swearing from getting voiced out as being presentable takes
| the priority? The way our society is progressing right now,
| such evolution seems to be the direction that we all will take
| eventually.
| tsukikage wrote:
| "In 2018, Adam Farley, a contributor to the OpenJDK project, the
| presence of profanity in the source code."
|
| Someone accidentally a verb.
| koromak wrote:
| "As part of your study, reviewed and analyzed over 3800 open
| source code containing profanity in English and over 7600
| profanity-free open source code on GitHub."
|
| Wow, over 3800 code? Thats so many code! And its _my_ study?
| Even better!
| jraph wrote:
| They didn't their sentence.
|
| It makes it quite.
| pyeri wrote:
| Probably same goes about the people? The emotionally charged
| person that swears and gives a mouthful usually ACTS better than
| the cold calculated one that speaks the right words but full of
| cunning inside?
| dev_snd wrote:
| Here's the link to the original full PDF:
| https://cme.h-its.org/exelixis/pubs/JanThesis.pdf
| jansommer wrote:
| I sometimes feel like swearing in the comments or commit
| messages, which can be the first thought coming to mind, and
| spend a few resources on writing in a kinder way.
|
| Perhaps I could use this as an excuse for not reaching a
| deadline...
| twodave wrote:
| Article should have included some juicy examples. 4/10
| happytiger wrote:
| Fuck yea it is.
| bawolff wrote:
| 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
| gweinberg wrote:
| Nobody suggested causation. The idea that you can improve code
| quality by adding profane comments is so self-evidently absurd
| that nobody would even suggest such a thing. Except you kind of
| just did.
| MoSattler wrote:
| So, you're saying that my code won't improve simply by
| sprinkling F-Bombs everywhere?
| bawolff wrote:
| Correct: fork bombs rarely help
| passwordoops wrote:
| There's only one way to find out!
| mikrl wrote:
| The C code so impressive they had to remove it from K&R:
|
| if (*some_bullshit >= shit_tolerance){
|
| fucks_given = 0;
|
| exit(IM_DONE);
|
| }
| HeyLaughingBoy wrote:
| Why bother setting fucks_given if you're exiting?
|
| mmm
|
| /embeddedme says it _could_ be a memory-mapped peripheral
| that needs to be reset on exit. But that 's a stretch.
|
| Why am I even thinking about this?
| rfw300 wrote:
| I don't think anyone is saying it's causation, the correlation
| is in and of itself interesting!
| bawolff wrote:
| I mean i think the article is implying that. However i think
| the bigger thing is the correlation is misleading due to the
| sample being the long tail of github projects, which i dont
| think is representitive of "production" open source projects
| and certainly not software in general.
| bitofhope wrote:
| Rorschach test for programmers: give your confident gut feeling
| explanation for this phenomenon.
|
| I'll do mine: there's likely a correlation between needing to
| maintain a professional conduct which includes forgoing foul
| language (you're programming at work) and writing code under
| time pressure where getting a product ready for release is more
| important than strict adherence to clean programming practice
| (you're programming at work).
|
| Everyone post your favourite conjecture!
| bawolff wrote:
| This seems unlikely to be true in this case because the study
| was looking at github projects, and it seems unlikely the
| sample had enough code from "uptight" work places, to have an
| affect one way or another
| painted-now wrote:
| My gut feeling: when you start to submit swear words in your
| code, it indicates that you "breathe" the code and know it in
| and out.
|
| The other extreme: if you have no idea what you are doing,
| you might try to mimic "corp speak" in your code to hide the
| fact that you actually have no clue.
|
| In other words: it needs some confidence in your ability to
| assess some aspect of the code in order to use swear words.
| dogleash wrote:
| > Everyone post your favourite conjecture!
|
| Places uptight enough that developers never swear in comments
| are uptight in other ways that lead to poor team dynamics
| which hinders quality.
| jerf wrote:
| Everything is correlated: https://gwern.net/everything
|
| Take almost any two things like this and you're actually
| virtually guaranteed to draw out some weak, but quite likely
| statistically significant, correlation.
|
| What lies behind that correlation is probably a entropic
| mishmash of so many factors that it defies human explanation,
| and also, defies any attempt to try to "harness" the forces
| that seem to appear. It could be that _all_ the siblings to
| the comment are right all at once.
|
| I'll cop to just glancing at the graphs, but they don't look
| out of line for this effect to me intuitively.
|
| Also backing this is that more-or-less the same
| article/thesis could easily have been written for the
| opposite correlation.
| lcnPylGDnU4H9OF wrote:
| The developer who knows what they're doing is also more
| likely to be 1) overworked because they do much of the useful
| stuff and 2) cognizant of bureaucracy which gets in the way
| of them doing useful stuff.
| zitterbewegung wrote:
| I would bet the opposite because I can make a blind assertion.
| bawolff wrote:
| You're beting that people swear in code in order to impress
| future employers?
| gtirloni wrote:
| No, they are saying your argument is baseless and they can
| do the same.
| bawolff wrote:
| Can they though? Like sure its pretty easy to idly
| speculate, but instead of doing that they decided to
| claim the opposite. My claim, well i wouldn't call it
| baseless since its based on the study protocol in TFA,
| certainly might be wrong. But the opposite claim is
| almost surely wrong, to the point of being absurd. Which
| is the claim they made.
| jghn wrote:
| 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 impressed by this.
|
| Not that I think it's *bad* per se, I'm not clutching pearls or
| anything. But I never find myself thinking what the code really
| needs are profanities in the comments. Whereas back then I
| thought it'd be funny/cool and went out of my way to do so when
| I could. Which wasn't often.
| nomel wrote:
| I wonder if swearing can help "free the mind" in some way,
| with the "rebellion" opening up more, perhaps non-
| standard/out of the box, "fucking good" ideas?
| eastbound wrote:
| or express a wide range of subtlety.
| seadan83 wrote:
| I hear this, comments generally should not draw attention to
| themselves. For this, short & terse win. I routinely look to
| cut any unnecessary words from comments.
|
| 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.
| moonchrome wrote:
| Being passionate about code correlates with quality - shocking
| betamike wrote:
| I skimmed the paper, and it looks like they are looking for
| swearing _anywhere_ in the repos' code, not just comments.
|
| I would be curious to see the ratio of swearing in comments vs
| code identifiers. I'd also be curious to see if the repos with
| swearing in their comments just have more comments in total.
| Perhaps the correlation is, "code with more comments is more
| likely to be higher quality".
| tombert wrote:
| The jury is still out if I'm a good programmer, but I did one
| time need to use a hashmap that had to grow to about ~100gb in
| size. Because of that, I ended up calling it "bigassHashTable".
|
| It makes me happy that it remained being called that for quite
| awhile.
| squeaky-clean wrote:
| I remember a day at a previous job when our CEO came in and
| told us we weren't an early stage startup anymore and had to
| start acting like it. Remove profanity and inside jokes from
| the code, and no more Quake during lunch breaks. Morale took
| a big hit that day.
| KerrAvon wrote:
| if a CEO did that to me I'd just tell him to pull the stick
| out of his ass. none of it has anything to do with
| maturity.
|
| but I'm relatively old.
|
| you can Quake (or Overwatch or whatever the current game
| is) during lunch breaks at every FAANG, for christ's sake.
| (it's different if you're playing it during working hours.)
| MountainMan1312 wrote:
| Time to unionize over that crap
| DonHopkins wrote:
| Swearing in the comments is for goodie goodies. Bad assed
| programmers swear in public apis like class names, functions,
| variables, and documentation!
| blarghyblarg wrote:
| The best programmers I've worked with swore at their
| coworkers regularly, but never in their code.
|
| They were not great people, and I'd happily kick them in the
| face if I would encounter no legal or professional
| repercussions, but, there definitely does seem to be some
| correlation (in my experience) between being abrasive and
| being a skilled programmer.
| ftxbro wrote:
| apotheosis in terry davis
| paxys wrote:
| Coworkers who swear are just more memorable. Plenty of
| great ones quietly get the job done without a fuss and
| without seeking to always cause a scene.
| stainablesteel wrote:
| someone hired a team to review 10k repos just for this?
| bjornsing wrote:
| Sure, that means someone cares.
| KolmogorovComp wrote:
| 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.
| nomel wrote:
| From the article:
|
| > This means that swearing will not automatically improve the
| quality of your code.
| bitofhope wrote:
| Sounds like you're suggesting a causal relationship the other
| way, though. As per this explanation, putting effort into
| debugging edge cases will statistically cause the comments to
| swear more.
| fsckboy wrote:
| > _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, including every time we conduct an
| experiment about it; but still we have no cause to point to.
| WalterBright wrote:
| Maybe gravity causes matter.
| fnordpiglet wrote:
| When we open sourced the Netscape Navigator a major undertaking
| was code sanitation. This including excising licensed libraries
| etc (resulting in an initial release that wasn't able to
| compile), but also removing enormous amounts of profanity and
| references to how evil Microsoft was.
| DonHopkins wrote:
| JWZ sure could flame in the comments, especially about Motif.
|
| http://www.art.net/~hopkins/Don/unix-haters/x-windows/motif....
| gweinberg wrote:
| I've noticed the same effect in HNN posts. The more profanity
| there is the comments, the better the original post!
| Unfortunately there's no good way to take advantage of this;
| optimizing to the metric destroys the value of the metric.
| gridspy wrote:
| My Hypothesis
|
| 1. Passionate developers often swear more often when they feel
| safe to do so
|
| 2. Developers work better in a "safe environment" where they are
| not judged / forced to follow other guidelines by social or
| employment pressure.
|
| And another point : those places where it's unsafe (often due to
| managerial micromanagement) are miserable places to work. That
| can drive away skilled developers or suppress them if they
| remain.
|
| All this is assuming the research metric is real, though I'm not
| sure it is. If the metric for "code quality" is actually
| "precision following a coding standard" you'd have though that
| rigid adherence to procedure would lead to a higher score?
| z3t4 wrote:
| Or that those that need to adhere to strict linters, formatting,
| etc are less happy with their life and thus use more profanity.
| eg. "code quality" tools that does not have any benefits besides
| finding potential bugs that does not effect the state of the
| program, like lines that are 71 characters long instead of 70
| characters.
| whoopdedo wrote:
| 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. First
| control for comment density. Then compare code quality to
| swearing in comments and also variable names.
| mr_00ff00 wrote:
| Isn't commented code no longer considered a good idea in most
| companies?
|
| I used to work for a bank and the policy is no comments unless
| absolutely necessary, because comments become out of date.
| Doxygen is the only real comments allowed.
| IshKebab wrote:
| 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.
| ckdot2 wrote:
| 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 update the comment? most
| developers will not. this risk is ALWAYS present if the
| comment explains more than the nearby code. so a comment is
| only safe if it contains the same degree of information
| like the nearby code. in that case though the comment is
| redundant. comments only make sense if they explain the
| -why-, not the -what- or -how-.
| gpderetta wrote:
| That still valuable as it explain the original intent of
| the code, especially together with vcs history. When
| debugging strange issues even cryptic hints can be
| useful. Even merely the fact that someone thought that
| commenting a specific bit of code was required can be
| valuable.
| IshKebab wrote:
| 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 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.
| gpderetta wrote:
| Besides, even function names can go out of date, yet we
| still give functions meaningful names.
| hakunin wrote:
| Pasting again my 4 reasons to leave a code comment:
|
| 1. An odd business requirement (share the origin story)
|
| 2. It took research (summarize with links)
|
| 3. Multiple options were considered (justify decision)
|
| 4. Question in a code review (answer in a comment)
|
| And the article on how/what/why in code:
| https://max.engineer/maintainable-code
| ikekkdcjkfke wrote:
| If the code doesn't speak for itself...
| hakunin wrote:
| ...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.
| josephg wrote:
| I'd also add:
|
| - The code is not self describing for some reason (eg duffs
| device, complex math, non obvious cases, etc)
|
| - The code is correct but it looks intuitively wrong. This
| comes up every few thousand lines for me, where some
| conditional looks redundant or twisted up for some reason -
| like maybe there's weird choices to keep the borrow checker
| happy. I leave a note to myself because next time I read
| that code I'll want to "fix" it.
|
| - Internal function preconditions / invariants. Eg, "this
| method must only be called while the XXX mutex is held" /
| "this code can only be reached when YYY is true because
| <reason>". Sometimes these checks can be cheaply expressed
| in assertions, but not always. And sometimes you need
| comments as well to describe the nuances of what's going
| on.
|
| Rereading my comment, maybe these are all examples of
| comments used to support code that's not self describing.
| I've been programming for about 30 years now. I don't think
| self describing code is always possible or desirable. I
| prefer fewer, longer functions with comments than digging
| through dozens of tiny functions spread everywhere. Large
| functions are usually easier to write and to read.
| hakunin wrote:
| I agree with this, and some of this does come up in code
| review questions (point #4). Sometimes you can already
| predict a question or predict a mistake someone is likely
| to make, especially knowing your colleagues/context. In
| those cases a preemptive comment makes sense, but only if
| you couldn't somehow define that mistake/misconception
| out of existence in the code itself.
| fx1994 wrote:
| that's why three and I think the fourth will leave our
| company after original developer left undocumented and hard
| to understand code (it's pretty complex and has tons of hacks
| to work on different OS'es), first year they learn what the
| hell is that code, how it works and they are not allowed to
| comment anything (I asked few times why we waste so much time
| for basic stuff, they said it is unnecessary...ok I guess).
| Now they hired original developer for tons of money just to
| consult newest developer and explain him code. Reasonable I
| guess.
| almet wrote:
| I'm not sure the ratio of comments to LoC is a sign of good
| quality code.
|
| Too many comments might actually be a bad thing. It's more
| lines to maintain, and sometimes the comments just tell what
| the code is doing where there is no need to.
| brazzledazzle wrote:
| I find that comments are most valuable when
| onboarding/understanding an unfamiliar code base. Comments
| composed of a little bit of "what" some "where" and a lot
| of "why" seems best for this scenario.
| vezuchyy wrote:
| If you have a process where every commit is well documented,
| you don't need much comments since you can rely on whatever
| is your analogue for git blame. It's not a lack of comments,
| it's actually the opposite but aside from the code base.
|
| When I worked at SAP where VCS for ABAP is ancient and has no
| analogue for git blame we had a practice of putting a SAP
| Note next to every code change, since some of the things that
| we had to implement are dictated by business/legislation, so
| you need a proper explanation from time to time. Without it,
| the code becomes unmaintainable.
| ShadowBanThis01 wrote:
| 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.
| josephg wrote:
| 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.
| tormeh wrote:
| 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.
| ShadowBanThis01 wrote:
| Maybe you're a contractor. Maybe it's legacy code that
| has simply been archived. Maybe the network is down.
| Maybe there was a bad migration.
|
| Sidecars generally suck because they get lost.
| smrtinsert wrote:
| I get where they are going with it - every block of code
| should probably be obvious and final since it has one item to
| do well. Unfortunately there are always times when n random
| fields will be used for a conditional that is completely non-
| obvious. Comments will always be necessary to some degree.
| makeworld wrote:
| Wow, that seems strange to me. Seems like the policy should
| be to make comments when needed, and keep them up to date.
| paxys wrote:
| That's an idiotic policy and definitely not something that is
| industry standard.
|
| Code gets out of date as well, so let's just stop writing it
| altogether..
| pasquinelli wrote:
| the code can't get out of sync with itself. i agree, that's
| a dumb policy. boilerplate comments are just as bad as
| boilerplate code-- the policy should be to comment when
| something is notable, in the manner that's appropriate for
| the context.
|
| but comments telling you one thing is happening when
| something else is happening is a problem, and i suppose it
| couldn't happen if the comments weren't there.
| jacobsenscott wrote:
| Even better, lets triple the work and require UML diagrams,
| comments, and code to all be in sync at all times!
| chinchilla2020 wrote:
| don't forget the random google sheet that the project
| manager wants to keep updated
| dylan604 wrote:
| you left out keeping the docs in sync as well
| ckdot2 wrote:
| If code is wrong or out of date, the program will fail or
| stop doing that it's supposed to do. If comments are wrong
| or out of date, it will mislead the developer or at least
| confuse them if the comment says something else than the
| code. A wrong comment is worse than no comment - and
| usually developers don't care about comments as much as for
| the code. Why comment some code anyway if the code is easy
| to read? The only reason is to explain -why- something has
| been developed, not -how-.
| flatline wrote:
| 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
| commented. Generally I've found uncommented code bases to be
| thrown together haphazardly and to be of lower quality. Same
| with those that only trivially leave comment breadcrumbs
| about what is being done, duplicating the code itself.
| bravetraveler wrote:
| "Why" is a really good way to put it, like you say - doing
| "What" just repeats something a novice, possibly even a
| layman, could distinguish.
|
| I tend to treat them like a strange hybrid of a story with
| editor's notes.
|
| Here's where we're going... but oh no! Something is in the
| way. We need this critical, but painful to acquire shovel.
|
| If I anticipate even the slightest bit of refactoring
| around it, I'm noting what devilishness lead me down this
| path.
|
| TLDR: anything that could be abstracted away/not exist,
| probably deserves comments on _why_ it does... perhaps even
| _how_ it could be removed.
| bsder wrote:
| > "Why" is a really good way to put it, like you say -
| doing "What" just repeats something a novice, possibly
| even a layman, could distinguish.
|
| And "profanity" in code is almost by definition a
| "Why"-type comment.
|
| You don't get upset and leave a profane comment unless
| you did a deep dive and realized the code does something
| absurdly horrible that took you far too long to figure
| out.
| slily wrote:
| It depends on the domain. I would be cautious about
| assuming that concise comments explaining what is being
| done in a block of non-trivial code are unnecessary. I
| have seen too many people write code they assume to be
| trivial (after spending days/weeks/months/years
| developing necessary background knowledge to understand
| it) when it's not the case at all. Debugging errors in
| undocumented code that involves several complex/opaque
| structures, nested function calls, and external libraries
| is not fun when you can't tell what step is at fault due
| to side effects, internal computations etc. not being
| clearly visible.
| bravetraveler wrote:
| That's completely fair!
|
| There have been cases where very slight changes in
| methodology completely fall apart - reasons varying.
| Timing, cache fit, and whatever else you may think of.
|
| Jenkins is something I've been picking up lately, and the
| 'DSL' has a ridiculous number of quirks
| dylan604 wrote:
| in procedurally written scripts, i write "what" comments as
| an outline or roadmap. i also use # vs // differently where
| the // style designates these what so i can find next to
| jump to next section. if i ever get away from being a solo
| dev and work as part of a team, there'll be a lot of
| unlearning personal habits
| andruby wrote:
| What you describe as sections seem like natural breaking
| points for function. Split of those section in their own
| named function. The names help to document, make it
| easier to test and the calling of the functions will give
| a high-level overview of the processes
|
| Ie: def drive turn_ignition()
| shift_gear() press_accelerator() end
| def turn_ignition ... code end
| def shift_gear ...
| [deleted]
| 7thaccount wrote:
| Ever read a Fortran code base? I once worked with a vendor
| that had nearly zero documentation, but at least you could
| get source and it was very well commented. You could spend
| a few hours and actually learn what was going on. The
| comments helped get enough of an idea to where reading the
| code wasn't too bad. I don't think I would've had the
| patience to only read the code without some assistance in
| what I should be looking for.
| chinchilla2020 wrote:
| I have been known to leave long comments or links to
| confluence for the purposes of QA and testing. Sometimes
| integration tests require special utils and in the worst
| case code modifications to work properly in a mocked
| production environment. Often this is outside the control
| of my own working group since I tend to work for giant
| megacorps.
|
| Any tester is going to need detailed information that is
| devopsy and cannot be expressed in pure code (Despite the
| claims spoken by the code-as-infrastructure tools).
|
| There are also cases where I like to document the living
| shit out of my classes/functions if they are something that
| will be used by many other devs. Bash/unix functions are
| some of the most heavily-documented tools you will ever
| see. Try using 'man grep'.
|
| There are more questions than "why" that can be answered by
| comments. There are also "What ifs" that you could
| anticipate. Many of those "what ifs" are almost certain to
| appear in certain circumstances, and I choose to drop a few
| breadcrumbs that can save the code maintainers a few weeks
| of their time rather than following a false lead.
|
| The beauty of code comments is that they don't require some
| external tool. They are in the pudding with the code
| itself, where they can be found easily. Most IDEs allow you
| to collapse long comments and even fade comments into a
| light grey so they aren't distracting.
|
| From this thread and work experience I know that the code
| commenters are losing our war and are pretty much defeated
| by the code aesthetics crowd - who insist code should be
| beautiful before being useful.
| throwaway14356 wrote:
| While I carefully keep others away from my code the notes say
| I have a complicated relationship with my future self. While
| comments should be the least useful to me I've tried many
| formats and found that it is spectacular to have the full
| elaborate comment above each bite sized nugget of code. I
| mean that what was solved as a single thing after breaking
| down the larger problem.
|
| The result is that I don't read any code at all. The whole
| thing is compiled to the native format that is human
| language. The code is great for illustration.
|
| If I keep it in separate files as documentation it takes to
| much effort to find and update. It takes needles extra effort
| and is less precise.
|
| It is just a personal preference of course but if one had any
| experience writing code in any language it should be easy to
| grasp say at 4 am while drunk.
| furyofantares wrote:
| No-comments are better than low-effort, low-quality,
| unmaintained comments, for sure.
|
| You can imagine a world where all the projects that aren't
| realistically going to spend the effort on high-quality
| maintained comments makes the correct choice to skip comments
| unless absolutely necessary. And where projects that are
| realistically going to put effort into high-quality,
| maintained comments, do so.
|
| In this world, comment density would correlate highly with
| code quality per line of code. Profanity might not, I'm not
| sure. I do think you'd still find profanity in high-effort,
| high-quality, maintained comments, but it might indicate
| lower quality surrounding code, not higher.
|
| And it would still be unclear whether the existence of
| comments are a cause of higher quality code, or just a proxy
| for amount of effort and care taken per line of code.
| slowmovintarget wrote:
| That assumes that most comments contain cursing.
| comfypotato wrote:
| No it doesn't. If any more than 0% of comments contain
| profanity, then on average code with more profanity will be
| better.
| jacobsenscott wrote:
| I never write comments, and I think they typically have a
| negative correlation to quality (this code is so f**ed up,
| plain english is, of all things, more clear and precise than
| code!). Unless you are releasing code publicly, and you are
| documenting the public API, I've never seen a valuable comment.
| I've seen plenty of harmful comments. However I wholeheartedly
| endorse using this otherwise useless but common language
| feature for swearing.
|
| I think swearing in comments indicates you are unburdened by
| bureaucracy and pointy haired bosses (because they prohibit
| such things), which would certainly lead to better code.
| chinchilla2020 wrote:
| you've never seen a useful comment?
| jacobsenscott wrote:
| I've been doing this for 20 years, so maybe? But I can't
| recall a single one excluding painstakingly maintained
| documentation for a public api where the source isn't
| readily available. I usually try hard not to read the
| comments and just read the code because comments are wrong
| so often.
| jacobsenscott wrote:
| [flagged]
| [deleted]
| tremon wrote:
| 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.
| balaji1 wrote:
| that's *** brilliant I @#@#@ know that feeling
| tessierashpool wrote:
| as long as we're designing the ideal experiment for someone
| else to do, let's throw in the commit messages as well.
|
| I wouldn't be surprised if code quality goes up with comment
| curses and down again with commit message curses.
| version_five wrote:
| 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.
| WalterBright wrote:
| > I remember reading that people who swear a lot are
| statistically smarter.
|
| 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.
| davely wrote:
| There is probably some cognitive overhead required to actually
| _not_ swear in certain situations, especially if you're prone
| to doing it.
|
| "What the f... heck is this, kiddo?"
|
| Definitely gotta utilize those brain wrinkles in that case.
| LeifCarrotson wrote:
| Failing to provide the typical social signals seems correlated
| either with extreme competence - they don't need to use polite
| language or other signals to boost employability - or with
| complete incompetence. There's a skill floor that cuts off the
| latter from this dataset when they can't configure an SSL
| certificate for their git client; their curses at "unable to
| get local issuer certificate" or "fatal: repository not found"
| are not uploaded to the Internet.
| ahamm wrote:
| 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 we have people
| writing papers like this - context is everything.
| DonHopkins wrote:
| The original terminal emulator terminal.el in gnu emacs, written
| by mly (Richard Mlynarik), was particularly salty. I finally
| tracked down a copy, but it looks like somebody complained and in
| 1990 it was begrudgingly cleaned up a bit, so some of the worst
| stuff was moved out into a separate file called term-nasty.el for
| posterity (you, here, now), so as not to give "in to the pressure
| to censor obscenity that currently threatens freedom of speech
| and of the press in the US" (oh, Richard <3 ):
|
| https://opensource.apple.com/source/emacs/emacs-59.0.80/emac...
|
| 1990-08-26 Richard Stallman (rms@mole.ai.mit.edu)
|
| * terminal.el: Move possibly offensive comments to term-nasty.el.
|
| https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
|
| [...] ;; disgusting unix-required shit
| ;; Are we living twenty years in the past yet?
| (defun te-losing-unix () nil)
|
| [...] ;; (A version of the following comment
| which might be distractingly offensive ;; to some readers
| has been moved to term-nasty.el.) ;; unix lacks ITS-style
| tty control... (defun te-process-output (preemptable)
| ;;>> There seems no good reason to ever disallow preemption
| (setq preemptable t)
|
| [...] ;; I suppose if I split the
| guts of this out into a separate ;; function
| we could trivially emulate different terminals
| ;; Who cares in any case? (Apart from stupid losers using
| rlogin)
|
| [...] (?\C-b .
| te-backward-char) ;;
| should be C-d, but un*x
| ;; pty's won't send \004 through!
| ;; Can you believe this?
|
| [...] ;; Did I
| ask to be sent these characters?
| ;; I don't remember doing so, either.
| ;; (Perhaps some operating system or
| ;; other is completely incompetent...)
|
| [...] ;;-- Not-widely-
| known (ie nonstandard) flags, which mean
| ;; o writing in the last column of the last line
| ;; doesn't cause idiotic scrolling, and
| ;; o don't use idiotische c-s/c-q sogenannte
| ;; ``flow control'' auf keinen Fall.
| "LP:NF:" ;;-- For stupid or obsolete
| programs
| "ic=^p_!:dc=^pd!:al=^p^o!:dl=^p^k!:ho=^p= :"
| ;;-- For disgusting programs. ;;
| (VI? What losers need these, I wonder?)
| "im=:ei=:dm=:ed=:mi:do=^p^j:nl=^p^j:bs:")))
|
| [...] (setq te-process
| (start-process "terminal-emulator" (current-buffer)
| "/bin/sh" "-c" ;; Yuck!!!
| Start a shell to set some terminal
| ;; control characteristics. Then start the
| ;; "env" program to setup the terminal type
| ;; Then finally start the program we wanted.
| (format "%s; exec %s"
| te-stty-string
| (mapconcat 'te-quote-arg-for-sh
| (cons program args) " ")))))
|
| [...] ;;;; what a complete loss
|
| [...]
|
| https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
| ;;; term-nasty.el --- Damned Things from terminfo.el ;;;
| This file is in the public domain, and was written by Stallman
| and Mlynarik ;;; Commentary: ;; Some
| people used to be bothered by the following comments that were
| ;; found in terminal.el. We decided they were distracting, and
| that it ;; was better not to have them there. On the
| other hand, we didn't want ;; to appear to be giving in
| to the pressure to censor obscenity that ;; currently
| threatens freedom of speech and of the press in the US.
| ;; So we decided to put the comments here. ;;; Code:
| These comments were removed from te-losing-unix. ;(what
| lossage) ;(message "fucking-unix: %d" char)
| This was before te-process-output. ;; fucking unix has
| -such- braindamaged lack of tty control... And about
| the need to handle output characters such as C-m, C-g, C-h
| and C-i even though the termcap doesn't say they may be used:
| ;fuck me harder ;again and again! ;wa12id!!
| ;(spiked) ;;; term-nasty.el ends here
|
| Note to the gentle readers: "wa12id" stands for "with a 12 inch
| dildo".
|
| Jamie Zawinski kept Lucid Emacs nasty:
|
| https://groups.google.com/g/gnu.misc.discuss/c/U5oXKOfWinQ/m...
|
| Noah Friedman, Aug 3, 1992, 4:54:20 AM
|
| In article <15i2n9...@hal.com> wood...@hal.com (Nathan Hess)
| writes:
|
| >In article <FRIEDMAN.9...@nutrimat.gnu.ai.mit.edu>, friedman@gnu
| (Noah Friedman) writes:
|
| >>It's by no means necessary, but it's _funny_.
|
| >Along the same lines, look at lisp/terminal.el
|
| Of course, terminal.el is actually useful, albeit not terribly
| powerful.
|
| (and terminal.el is pretty mild compared to some of the other
| things I've seen written by mly. :-))
|
| Incidentally, a lot of terminal.el has been rewritten in version
| 19.
|
| Too bad... I liked all the variable names and comments in the
| original.
|
| Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
|
| In the FSF-distributed Emacs 19, the obscenities (will) have been
| stripped from terminal.el, though they are preserved in a file
| called term-nasty.el, to avoid appearing to bow to the censors.
|
| In Lucid GNU Emacs, terminal.el will remain as nasty as it ever
| was.
|
| -- Jamie "Truth, Justice, and the Fucking First Amendment"
| Zawinski
| skrebbel wrote:
| My pet theory is that this is because honest, emotional comments
| are much more useful than the usual "professional" style that try
| to hide it when you have no clue what you're doing.
|
| When it's clear someone was stuck, frustrated, banging their head
| against the wall etc while writing a particular bit of code, you
| can refactor a lot less defensively because you know the crappy
| parts weren't secretly there for a reason.
|
| I love real, honest, emotional comments. Pour all the frustration
| in there. Future you and your colleagues will thank you.
| jamesgreenleaf wrote:
| I think so too. Profanity, in small amounts, is an indicator of
| honesty.
|
| Everyone swears sometimes. If you never do it in front of
| others, it signals that you're always filtering yourself.
| vharuck wrote:
| Possible explanation: swearing is more likely to be committed
| into code by people who either (1) own the code, or (2) know
| they're too valuable to be punished. So it self-selects.
|
| I personally have very different commenting styles between my
| work and personal projects. Not that any of it's good.
| moffkalast wrote:
| Possible explanation: The code for the fast inv sqrt is copy
| pasted everywhere and is skewing the results.
| atleastoptimal wrote:
| Imo, it's because swearing indicates frustration, and
| frustration indicates effort.
| throwaway8689 wrote:
| So I need to use more profanity at work, then ask for a
| raise?
|
| (But I concede that effort and productivity are not the same
| thing.)
| monksy wrote:
| Alternative explanation in the same vane as your theory:
|
| The cognitive and time cost of compliance for language policing
| takes away from valuable programming and planning involved in
| developing solutions. (i.e. "banned words" [swear words] and
| politicalized words [whitelist/blacklist,etc])
|
| Antoher possibility is the people who don't want to deal with
| that are gone and we're seeing a loss of their contributions.
| BolexNOLA wrote:
| That's a pretty big leap IMO. What gives you that impression?
| blarghyblarg wrote:
| https://www.sciencedirect.com/science/article/pii/S18770428
| 1...
|
| It's really not a big leap, though. People who are afraid
| of violating a code of conduct because they're "under the
| watch of language police" are basically experiencing a form
| of anxiety that may or may not have a basis in reality.
|
| Being afraid of being sent to the HR DEI board because you
| named a process 'Child1' then ran Kill(Child1) ... or any
| less obvious scenario similar to that ... is not going to
| do great things to your ability to work.
| BolexNOLA wrote:
| This tells me more about the impacts of anxiety writ
| large than it highlights the problem of "language
| policing."
| [deleted]
| MacsHeadroom wrote:
| Not that commenter, but with 20 years of experience in open
| source I share their hypothesis.
|
| Language policing slows down technical progress, very
| significantly I would wager.
| BolexNOLA wrote:
| I guess I should put it another way. Sure it's a valid
| theory, but I think asserting it as borderline self
| evident/a big enough deal that it primarily explains the
| profanity in repos is another matter entirely. I could
| also assert 5 other valid theories I'm sure. Doesn't mean
| they're all accurate or worth weighing.
|
| So yeah, I'm just curious how those of you who responded
| to me are quantifying this.
| BolexNOLA wrote:
| If I find someone with 20 years experience that disagrees
| with your take, what then? I'm just wondering how y'all
| are quantifying this, as I explained in another comment.
| stcroixx wrote:
| Agree. You'll never get a count of all the people who may
| have been interested in contributing to a project but
| decided against it because of a COC or language police.
| monksy wrote:
| I would also argue that it prevents important technical
| conversations and accounting. If you have a m/s
| architecture, and you're concerned about
| redudancy/cost/etc.. well that conversation has been
| delayed and potentially prevented over the constant
| correction of saying manager/worker instead. It's a
| mental/cognitive/communication tax on the contributors.
| monksy wrote:
| Everything has an opportunity cost. It's just often not
| explicitly realized or acknowledged.
| aosmith wrote:
| This is a normal part of software... You find something really
| bad, git blame says it's your own, you leave a vulgar comment
| about how bad it is for the next guy.
| ftxbro wrote:
| now we let goodhart's take its course
| sircastor wrote:
| Anecdotally, it seems to me that I work with a lot of folks that
| swear frequently but not in their code comments.
| pak9rabid wrote:
| // fuckin eh
| paxys wrote:
| I'd first like to know how they judged what is "good" vs "bad"
| code.
| francasso wrote:
| This is an example where correlation does imply causation IMHO
| ftxbro wrote:
| adding swears into codebases would improve their quality
| grayhatter wrote:
| The author of the paper suggests it's because the author of the
| code cares more, and is more passionate. Do you think it's just
| random chance there is a correlation, or do you have a better
| explanation for the results?
| yongjik wrote:
| Sorry for being off topic, but let me introduce you to the only
| true metric of code quality: WTF/minute.
|
| https://www.osnews.com/story/19266/wtfsm/
|
| One wonders if profanity in the source code interferes with
| reviewers and skews this important metric ...
| cjsplat wrote:
| While at Sun in the early 2000's, I was part of the due diligence
| team for an acquisition and had two days to review the entire
| code base of a 3 year old, 50 person software team.
|
| This was standard practice, and the M&A policies knew that there
| was no way to actually understand all the code so there was a
| policy document to describe what to look for.
|
| Of course the red flag things were unexpected 3rd party
| copyrights and/or license terms in case the code was encumbered.
|
| But "swear words" were on the yellow flag list, in addition to
| "ToDo", "XXXX", and "Fix Me" types of things.
|
| I remember thinking about places I have been in the past and that
| the people used those style comments tended to be the better
| programmers.
|
| I mentioned this to the person leading the evaluation, and was
| told that point of noticing these kinds of comments was to look a
| more closely at the nearby code and try to decide if major
| functionality was missing or being faked.
|
| It all worked out for that acquisition, but I remember being
| curious about whatever deal had gone bad in the distant past that
| made them codify this specific practice.
| mikecoles wrote:
| My code, by twisting this finding, is bug-free.
| BizarreByte wrote:
| I find it a bit suspect swearing would ever even get though a
| proper code review. It's extremely unprofessional, I would tell
| someone to remove it.
| MacsHeadroom wrote:
| And this is precisely how language policing slows down
| technical progress.
| KerrAvon wrote:
| you're from the east coast, aren't you?
| klysm wrote:
| At least in New England we swear quite a bit I'm not sure on
| what basis you are making that accusation
| klysm wrote:
| What harm does it cause?
| yk wrote:
| > Next, Strehmel and his team quantified the compliance of these
| two different sets of open source code with coding standards. The
| results were presented as an indicator of the quality of the
| source code through the SoftWipe tool.
|
| I would read that study as coding standards lead to profanity.
| (Not sure wether or not coding standards should be correlated
| with code quality, I just think it is obvious that the measure is
| correlated with the conclusion in an obvious way.)
|
| [Post posting:] Also looking at the plots, it seems that the two
| distributions are different, first the swear word distribution
| seems to be wider and second it has a clear outlier at "software
| quality" 8, so if anything it is an indication that something
| much more complex is going on.
| andrewedstrom wrote:
| I'm sure the top comment here will be something like "this is
| invalid because no way can you assign a numerical value to code
| quality! wtf?!"
|
| I'm withholding my own judgement on that.
|
| For anyone curious, the authors are coming up with a code quality
| score using an open-source tool called SoftWipe[0]. From the
| paper:
|
| > SoftWipe is an open source tool and benchmark to assess, rate,
| and review scientific software written in C or C++ with respect
| to coding standard adherence. The coding standard adherence is
| assessed using a set of static and dynamic code analysers such as
| Lizard (https://github.com/terryyin/lizard) or the Clang address
| sanitiser (https: //clang.llvm.org/). It returns a score between
| 0 (low adherence) and 10 (good adherence). In order to simplify
| our experimental setup, we excluded the compilation warnings,
| which require a difficult to automate compilation of the assessed
| software, from the analysis using the --exclude-compilation
| option.
|
| [0]: https://github.com/adrianzap/softwipe
| jtbayly wrote:
| The obvious question is whether the source code for this tool
| has profanity in it...
| scns wrote:
| Reminds me of a study. It showed, that swearing enables you to
| tolerate pain better. It was simple. Two groups, both had to put
| their hands into ice water. The group that was allowed to swear
| could do it longer.
|
| I'd hypothesize, that programmers, who actually care about
| quality, swear more.
|
| Individuals with AD(H)D might have a have a lower tolerance to
| pain. This, coupled with wide open sensual channels and decreased
| impulse control, might be a contributing factor.
|
| [Edit] added parenthesis and link
|
| Not correlated to swearing, but AD(H)D:
|
| https://www.youtube.com/watch?v=XdT4DIiX7Nk
| mpweiher wrote:
| > I'd hypothesize, that programmers, who actually care about
| quality, swear more.
|
| Ding ding ding, I think we have a winner!
|
| If you're not moved to profanity by most code-bases, you're
| either not paying attention or don't understand.
| ydnaclementine wrote:
| One rule I live by is I never ever swear in comments or commits,
| just not worth it. Even in personal projects.
|
| But one of my favorite projects to ctrl-f for "fuck" is in the
| jedi outcast source code. Since it is proprietary and was a good
| game: https://github.com/search?q=repo%3Agrayj%2FJedi-
| Outcast+fuck...
| mike_hock wrote:
| > Sign in to search code on GitHub
|
| lolwat
| arp242 wrote:
| > But one of my favorite projects to ctrl-f for "fuck" is in
| the jedi outcast source code.
|
| https://www.youtube.com/watch?v=R_b2B5tKBUM
| evilotto wrote:
| I'm guessing the multiple instances of i =
| 0x5f3759df - ( i >> 1 );
|
| in the results are one of those inverse-square floating point
| bit tricks.
| yodsanklai wrote:
| I'm surprised this is still a thing. I suppose this is associated
| with "toxic masculinity" which is frowned upon nowadays. I'm
| always a bit worried that I forget to edit my swearing and that
| it goes to code review.
| alpaca128 wrote:
| > Much of the community considers profanity as a vulgar display
| of lack of intelligence and education, because why use profanity
| when you have a rich vocabulary?
|
| Why not use the full range of one's vocabulary?
| bregma wrote:
| Ten thousand bilious blue blistering barnacles that's a
| tremendous idea!
|
| Or by "full range" did you mean "limit it to a few well-worn
| cliches"?
| charonn0 wrote:
| I only swear in commit messages. Am I doing it wrong?
| helmsb wrote:
| Correlation [?] Causation
| OnlyMortal wrote:
| Fuck that code!
| coding123 wrote:
| in other words, it increases the chance that the programmer is in
| a specific locale (like the US?) such that the location has less
| bad programmers than other locations.
|
| And probably, increases the chance that the person is fed up with
| fixing someone else's code - hence the anger
| twodave wrote:
| The best CS professor I ever had always said that the #1 language
| among programmers is profanity.
___________________________________________________________________
(page generated 2023-07-06 23:01 UTC)