101–110 of 221 posts
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.
> This means that swearing will not automatically improve the quality of your code.
Earlier quoted context omitted.
So, you're saying that my code won't improve simply by sprinkling F-Bombs everywhere?
The C code so impressive they had to remove it from K&R: if (*some_bullshit >= shit_tolerance){ fucks_given = 0; exit(IM_DONE); }
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?
Earlier quoted context omitted.
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.
That’s a pretty big leap IMO. What gives you that impression?
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
That’s a pretty big leap IMO. What gives you that impression?
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.
Earlier quoted context omitted.
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..
Even better, lets triple the work and require UML diagrams, comments, and code to all be in sync at all times!
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…
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.
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…
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
Ie:
def drive
turn_ignition()
shift_gear()
press_accelerator()
end
def turn_ignition
… code
end
def shift_gear
…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".
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.