Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

13

Case by case basis...comments are an avenue for a developers personality. Just as you have to deal with N types of personalties you also have to deal with N types of comments which bleed the developers personality. How do you deal with a given developer using profanity as you interact with them via IM, email, verbally?
–
Aaron McIverFeb 23 '11 at 14:44

9

I've had to tell some Jr. devs before not to put profanity in comments. IMHO it's very unprofessional. If you wouldn't swear in front of your coworkers or clients why swear in comments/code? And if you would swear in front of your coworkers and clients...then you have a much more laid back work environment than I do. :)
–
TyannaFeb 23 '11 at 15:01

9

Just do a grep f.ck on the source code of a Linux kernel. If it's good enough for them, it's good enough for me. But never ever put anything offensive in places where there's the slightest chance customers can spot it. I did it once and luckily we managed to pull the update in the last minute, but it wasn't fun. (Well, actually it was afterwards.)
–
biziclopFeb 23 '11 at 16:28

9

@Sergio, The conflation of racism with "bad language" offends me. I'd never tell a racist, sexist, or homophobic joke to anyone, no matter how well I knew them. But I have no compunction in telling you to fuck off.
–
TRiGMar 22 '11 at 13:16

7

@Sergio. The word "fuck" doesn't have a target. Some people don't like it. Okay. Big deal. The other words are expressly designed to target groups who are already disadvantaged in society. They make for a hostile work environment. If you don't see a distinction there, you're badly in need of education. Try derailingfordummies.com for starters. It's not directly on topic, but it will help, and it's the first thing that comes to mind.
–
TRiGMar 22 '11 at 18:36

14 Answers
14

..you cannot possibly know who will get to see the source code over its' lifetime.

While it is all part of the job to get frustrated with a particularly complex or old piece of code and want to sound off about it, putting expletives/rants/ASCII art/bad jokes/offensive remarks into the source code is both unprofessional and a bad idea in my experience. Sometimes, the engineer writing the comments is oblivious to the eventual effects his comments could have - here are just some of the issues I've see:

A high number of expletives in code released to the public as open-source/sample code.

Jokes in poor taste causing deep offense to some team members resulting in industrial tribunal.

Throw-away remarks that were actually racist/sexist/gender-ist causing people to be fired.

While we all need to have some outlets for frustration/fun/japing about, the source code is not the place to do this, IMO. You wouldn't put expletives/jokes/offensive comments in a Contract, Help Pages, Blueprints, or other professional document, even though those documents may be read even less often than the source code.

If team leaders get all heavy-handed about it, there's going to be upset, so I say 'gently discouraged' by means of a quiet word with problem engineers and provided suitable venting mechanisms to let off steam, whether that be Facebook, instant messaging, air hockey or a punch-bag.

It's no defense to say that comments are compiled out either - what about JavaScript, or any other dynamic client-side code?

Here are some of the real-world experiences I've had that have shaped my opinion:

While working at Microsoft, I spotted that one software engineer didn't know the correct spelling of "couldn't" - he missed the o,l and d - and had peppered much of his code with long explanations of how he couldn't get X to work because Y person was causing problem Z. His code was great; his spelling was not so good. Suffice to say, any subsequent reviewer of this code (e.g. me) was alarmed to see a large number of random swears in the code. Some of this code went on to be shown to partners (driver writers). Imagine their horror at seeing the swears. The rants ideally should have been to the project manager in verbal form (in which case person Y may be pulled in to the discussion) or perhaps commit messages, but not in the source.

At one company, a foreign-language-speaking individual joined a predominantly english-speaking team. He wrote comments in his language, thinking that nobody else could read them. This was fine, until Babelfish/Google Translate released a 'to English' option for his language, at which point the rest of the team translated a few comments and were appalled at the filthy and often derogatory comments the guy had been making about the company, his team and a female coworker. Awkward.

At another company, one guy was really taken with ASCII art and put all sorts of art into his source code, unspotted (or perhaps blessed) by code reviewers. After a while, he dwelled on dragons, for some reason, usually with some kind of tag line. Later on, a Welsh person joined the team. The national emblem of Wales is a red dragon, so the new guy was initially cheery about the pictures, but then offended when some of the silly tag lines could be construed as offensive. Yes, some team leader mediation required, but this shouldn't have happened.

I would add that profanity in your defect tracking system should not be encouraged either. Having been in the position of requesting a submitter to edit their commentary to remove the profanity, I can tell you this is not a pleasant position for a supervisor / team leader / manager to be in. Especially when they refuse.
–
quickly_nowMay 27 '11 at 6:56

@quickly_now, how did you handle that situation then?
–
user1249Nov 16 '11 at 6:55

I asked again. When the person refused again, I edited the comments myself to sanitise them. I did not think this was worth going through the process of counselling / disciplinary (step #1 leading to dismissal), but I also reported to my boss what I had found and done. We all agreed that it would go no further unless repeated (and it was not repeated). Not fun. [I should further add that the profane comments were reported to me by another member of staff who was concerned. That made it my problem to solve. Sometimes senior positions are not worth the extra $!!!]
–
quickly_nowNov 17 '11 at 12:02

If you're selling your source code (i.e. you're a component writer), it probably ought not be in there.

If it's a matter of prudishness, then well whatever, it's up to you.

If you see someone writing a lot of WTF's then maybe it's a sign that you should talk to them about the problems that they're having.

If someone is directing their aggression towards another persons code, then they might be harassing that person and you've got a completely different situation to deal with. Perhaps they have a legit complaint and don't know how to properly voice it. Perhaps they're just a jerk.

It wouldn't be wise to just have some sort of content filter, whatever a developer writes is important and it tells you a lot about how things are going.

+1 for the point about not selling explitive-laden source code. The code should be thoroughly inspected for such comments before being delivered.
–
FrustratedWithFormsDesignerFeb 23 '11 at 14:52

2

Rude comments are definitely not a good idea if you're a HTML developer. :)
–
biziclopFeb 23 '11 at 16:43

@biziclop, which is unfortunate because HTML is about as frustrating a language as there can be. Check out @the jinx's link about rates of profanity in source. looks like Javascript is tied for first (not sure if this includes accidental minified javascript cussing)
–
Peter TurnerFeb 23 '11 at 17:01

I work for a Fortune 500 company that designs, manufactures, and sells consumer products that have µControllers running code developed in-house. Litigation is always a possibility, either from consumers hoping to get rich quickly, or by competitors claiming infringement. Because of this, we write our code and ALL comments with the knowledge that it may (probably will) come under the scrutiny of hostile jurors at some time. That means that variable and function names should not include inciteful terms, like KILL_CHILD(int process_id). While the purpose of this example function could very well be to terminate child processes, how would a hostile jury view that function name if the plaintiff's child was killed while using the product?

In-code comments can be even worse. While a decent defense team could probably handle explaining what a child-process is (from previous example) and why it might need to be terminated, it would be nearly impossible to defend against a comment like:

// The following section of code is REALLY BAD!!! I hope
// it doesn't burn anybody's house down.

Off-hand comments like that have been deciding factors in real court cases.

On a related topic, names for projects can also be damning when under the microscope of intense litigation. Do you remember the uproar from the conservative groups in the mid '90s when technology news sources reported "SATAN Unleashed On The Internet" ?

< rant_mode_off >

With all that said, for personal projects you are free to do what you like in your code.

+1 for pointing out the most dangerous aspect of this UNPROFESSIONAL behavior. I've worked on "due diligence" teams that reviewed the source code of companies the F500 I worked for was about to buy. We looked for this kind of stuff for the reasons you mention and it made a difference who got offered continual employment and who didn't when the merger was completed. Specifically a large company (deep pockets) doesn't buy small company in order to inherit harassment/hostile work environment lawsuits so the offenders are terminated/made redundant when purchase is completed.
–
kloucksFeb 23 '11 at 20:47

3

KILL_CHILD is just an absurd example. And I'd like to see citation on "Off-hand comments like that have been deciding factors in real court cases." (I'm not just saying that as a STFU... I really would like to read the citation.)
–
WolfgerNov 16 '11 at 14:16

I'm inclined to agree that it can be quite unprofessional, but everyone cusses from time to time so I try not to hold it against others. That said, the codebase tends to reflect the overall professionalism of the group so an explicative laden codebase could reflect an unprofessional group and a meeting might need to be in order to "apply some polish" to the group. Likewise, if certain trends appear in the code, it could be an indicator of general problems within the group that need to be resolved (i.e. the API you are working with is has problems that are frustrating developers).

In terms of the codebase, I'll usually just edit the relevant comment to be safe for work and leave it at that. Depending upon the language you are working with, this is always a good idea as you never know what might appear in front of a client or customer.

I think its more dependent on sector - in a high-pressure environment such as finance, expletives are common.
–
JBRWilkinsonFeb 23 '11 at 18:22

it's also highly dependent on what you consider "profanity". Like in the article linked "lol" and "rofl" were chosen as profanity, when most of us I think won't class them as such.
–
jwentingFeb 24 '11 at 8:15

Its not about PC - its about appropriate use of language (you can be utterly not PC and still choose not to use profanity - you can be deeply offensive and rude and still not use profanity). It needs to be thought of in terms of not giving undue offence - undue because almost everything is offensive to someone - but most of us know where the line is and generally swear words are on the wrong side. Restraint in this area is useful - if you don't swear much or often then when you do people take notice...
–
MurphNov 16 '11 at 7:35

One of the problems with profanity is that it's different from culture to culture. In the US innocent stuff tends to get "bleeped out", while in other countries often you can hear the same language exchanged in parliament discussions.

Profanity in code and commit comments is quite common, likely because of the "nobody is going to see it" view. I think that it's actually more common now that most organizations outlaw easter eggs.

I personally think that non-customer facing stuff (such as internal commit materials) is not that big of a problem.

However, most large multinationals are run by legal departments and "safe workplace" and all that stuff, which means that anything that could be offensive to at least one person is a problem and potential cause for dismissal. I hate to admit it, but I tend to bow to the regulations of those who pay my salary.

A quick solution to this problem is to install a profanity filter on your source control system (as a presubmit script or a regular check).

I have to disagree with your suggestion of an automatic profanity filter. Firstly, you risk running into the Scunthorpe problem, and secondly, as Stephen C says, profanity is likely a symptom of another problem and banning it won't magically fix it.
–
ScottFeb 23 '11 at 15:31

profanity filters don't work. They tend to block innocious things and let bad things get past. They also tend to be easy to work around.
–
jwentingFeb 24 '11 at 8:19

cntd. I do moderation for a nature photography forum. When the admins decided to install a profanity filter, all discussions about beavers, peoples' pet pussycats, birds, etc. etc. would be censored. Before it was removed again, users started to develop ways around the filter. If you can't talk about your trip to shoot beavers (oops, 3 bad words in one short sentence), you talk about your tr.ip to sh.oo.t be.ave.rs instead for example and the filter'll be too stu.pi.d (another word that was banned) to catch it.
–
jwentingFeb 24 '11 at 8:20

To me the argument of avoiding profanity filters "because many of them are crap" makes as much sense as avoiding spam filters, sql sanitizers, etc. There are decent third party options out there. If you use just regexps, you're SOL.
–
UriFeb 24 '11 at 15:35

It is human nature for people to express themselves using "colorful language" in certain situations. More so in some cultures than in others, and some people more than others. But the tendency is universal.

If I were you, I'd shrug it off unless you are willing to make yourself unpopular with your workmates.

However, if the source code / VCS comments get published outside of your organization, your management might want to take a stronger line, on the basis that it is bad for business to offend your customers.

The key here is "in certain situations" - i.e. where appropriate and acceptable. I think it is reasonable to suggest that comments (code or commit) are not really acceptable places and therefore not appropriate.
–
MurphNov 16 '11 at 7:37

I think it's ok as long as it's not out of control like dropping f bombs over there. I have seen a guy I work with write a script between two characters discussing the various objects they each represent. There was a multiline comment that ran for like 30 lines of these two characters talking back and forth to each other.

It went on like this for a long time. He created two objects called, you guessed it: Frankenstein and Igor as part of some sanity check. It was actually very creative but a total waste of time. I would have rather have seen a few WTF's or expletives than a screenplay between two C# objects...

Depends on the culture of the company/client. For example, if you are developing Bible software, expletives in any form are definitely unwelcome. On the other hand, a game developer might not care so much (or go to the other extreme).

I'm always of the mind that any comments (in code or commits) should be helpful. Certain words catch our attention more than others--expletives, even the soft variety, definitely are noticed. It can be be useful to call attention to something that is just plain wrong but you have no way around it just yet.

That said, I don't use expletives but I will occasionally use things like "Doh!" or "Huh?" which is not too different in spirit. If it bothers you, talk about it with the offender--s/he may not be thinking about it. If they tell you to take a hike and you feel strongly about it, go a rung up to the manager. If you get no support from the manager, then you'll have to learn to live with it or go elsewhere.

Sorry, what is "Bible software"? (not an english native here).
–
RookFeb 23 '11 at 14:51

2

The Bible is where Christian doctrine is written down. Bible software is software that Christians can use to cross examine the text in different translations, look up what scholars have said about a certain passage, and in general study the text. One scripture talks about "Let no corrupt communication come out of your mouth" which is old English for don't cuss, or talk about things that tear people down. I'm sure there are other religious applications where cursing would be equally unwelcome.
–
Berin LoritschFeb 23 '11 at 14:54

As others have said, it depend on the workplace and who will see the source code.

If I was selling the source code I would have a second repository of only released versions and not allow any checkin comment in there outside of a description of what each new version provides. What I do on the day to day and all my missteps are between me and my team, not my clients.

Currently my build server reports on OMG, WTF, kludge, mess and TODO comments as a metric of remaining cleanup to do so right now they are part of the process.

If you see profanity in open source software and want to get rid of it, prepare for the possibility of push-back. Don't just write a three line bug report, and expect it to get accepted. Write a mini-essay explaining why profanity and discriminatory language is bad, and pre-empt the rebuttals.