Take the 2-minute tour ×

While reviewing a coworker's code, I came across some spelling mistakes in function names and also grammatical errors like 'doesUserHasPermission()' instead of 'doesUserHavePermission()' in function and variable names.

Should I point these out to him? Or am I being too pedantic to notice these ?

share|improve this question
I might be careful that the person actually wants help with their English, if it isn't their second language. Some people are content with knowing that they're not incapable of expressing structured thought, that they're just incapable of proper English. If English is their mother tongue, then yes, I think bad grammar is a problem. –  Rei Miyasaka Dec 28 '10 at 11:12
Yes. Its really frustrating when you have an API with wrong spelling. It spreads like wildfire. So its better to correct it as soon as possible. –  kadaj Dec 28 '10 at 12:29
@Rei: whether English is their native language or not should be irrelevant in a professional environment; if it's not then too bad for them but it's no excuse, they should be held to the same standards. –  Andreas Bonini Dec 28 '10 at 13:09
@Rei, many programming jobs I see advertised require proficiency in Native Languages for this very reason. Being able to discuss requirements, design, specification, and construction are all very important to the entire software product as a whole. –  Stephen Furlani Dec 28 '10 at 13:47
HTTP-Referer bothers me often. en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_term_referer –  a paid nerd Dec 28 '10 at 19:26

16 Answers 16

up vote 174 down vote accepted

Code with spelling and grammar errors is unmaintainable.

  • People won't remember the bad grammar, so they'll try to call the function as it should have been written, and that's how bugs happen.

  • You can't grep for something in the code if you don't know how it's spelled.

  • Most people who make grammar/spellings do so inconsistently, so they'll introduce many bugs with mismatched naming. This is particularly problematic in languages that don't require variables to be explicitly declared before use, because you can introduce a new spelling and your code won't come to a grinding halt to let you know you screwed up.

Correcting these problems is not pedantic, nor is it necessitated primarily by others' opinions of one's intelligence, literacy, etc (though that's a big side-effect); it is about writing quality, maintainable code.

share|improve this answer
+1 - pretty much exactly what I would have written. And spot on. –  quickly_now Dec 28 '10 at 5:57
+1 Sometimes sparing someones feelings is important, but when it's a code review ... if you catch it, it's fair game to comment. My company uses crucible for code reviews, which allows all reviews to see that it was caught and allows the reviewer to mark it not as a defect, but as style. –  opello Dec 28 '10 at 6:26
+1 - Once spelling and grammatical errors make their way into an API, they are nigh impossible to get out again. I spent the better part of three years having to write "Avtivity" instead of "Activity", and it always physically hurt to do so. –  John Bode Dec 28 '10 at 15:40
For better or worse, good programming practice often comes down to something very like pedantry. Plus, I'd like to find the person who misspelled Referrer in the original HTTP spec and kick him in the ankle. Of course, it was probably Berners-Lee and so I'd feel guilty afterward... –  Malvolio Dec 28 '10 at 20:17
@Stephan Furlani: that's the point I was trying to make; it was part of an API that we didn't own. We couldn't fix it on our end, and the process for getting it fixed was ugly and lengthy enough that nobody wanted to mess with it. –  John Bode Dec 28 '10 at 21:01

Yes definitely. It's easier to remember the name if it's grammatically correct. Trying to remember the name and grammar mistakes is another thing entirely.

share|improve this answer

Don't point them out as defects in a formal code review. Instead, mark up a listing and talk with him/her PRIVATELY about them. Be as diplomatic as possible about it, just "Hey, something I noticed, and I've run into people who REALLY look down on this kind of thing, they think it makes the programmer look careless and sloppy."

If this is code a customer is going to see, it absolutely MUST be corrected. Like it or not, it DOES reflect on your company's reputation.

For the example you gave, I suspect it started out as UserHasPermission, and someone else told him that local practice was doesUserBlahBlah() rather than UserBlahBlah(), and he just overlooked the grammar change.

share|improve this answer
Saying it's about others' perceptions makes it seem unimportant. Tell the truth -- they are making the code harder to maintain and build on. –  HedgeMage Dec 28 '10 at 5:19
@HedgeMage: My personal experience with things like this is that some people are EXTREMELY touchy about things they perceive as criticism of themselves. Worse, there can be really ugly political repercussions, if the person you appear to be criticizing is beloved by management. (Yes, I have the scars to prove this.) AND I have seen organizations that literally didn't care abou this kind of thing, as long as the code worked, for some definition of "worked". My personal feeling is that you have a better chance of getting it fixed, with minimal other headaches, if you go gently. –  John R. Strohm Dec 28 '10 at 5:31
@John I can certainly see that a bad work situation can force someone to have to walk on eggshells like that -- but it is a bad situation if that's an issue in the first place. Someone with so fragile an ego (and a workplace culture that allows their shenanigans) isn't good for business to begin with. –  HedgeMage Dec 28 '10 at 5:37
Most mature programmers accept criticism well. After all, thats what peer reviews are for (and we all do code reviews, don't we?) It is quite OK to critique the spelling and grammar of comments, function names, etc. It ALL reflects not only on the author but on their whole organisation. –  quickly_now Dec 28 '10 at 5:56
I gotta agree with HedgeMage here, if you can't point out mistakes like this during a code review (particularly when they're objectively wrong, like the example in the question) then you've got bigger problems... –  Dean Harding Dec 28 '10 at 5:59

Change it yourself.

Hopefully you're in an environment where code "ownership" is not an issue. If you have access to the project in source control, just go in and fix it yourself. If you see a particular coworker making the same type of grammar or spelling errors consistently, you might want to point it out, but that will depend on your relationship, whether the person is a native English speaker, and their general receptiveness. But whether you ever decide to do that or not, just quietly go and make the fix. I do this all the time, if I see a typo, especially in a method signature or public property, I just fix it. Occasionally I can't even resist the temptation to fix a typo in a comment, but that's just me :)

share|improve this answer
And then you find that you've just broken a third guy's code. You need to get these sorts of things fixed ASAP, not just when you can get to it after the first guy's checked everything in. –  David Thornley Dec 28 '10 at 15:14

I'm a developer whose native language isn't English, it's Dutch actually, and wouldn't mind at all if someone would point me a grammar or spelling mistake. In that way I can constantly keep improving my English. And it is certainly not difficult to correct all the mistakes in all of your source code. A simple Perl script can easily be written to loop thru all files in a folder. Perhaps even it can be done with sed? I don't know.

So I would certainly point out grammar or spelling mistakes in someone else's code, but only if I'm absolutely sure wether it is correct what I'm saying.

share|improve this answer

I agree with other answers saying that code with grammar mistakes is unmaintainable.

I also want to add a few things:

  • Code is often written by people who don't speak English very well and/or English is not their native language. If there is a grammar mistake in a code you review, this does not mean that your coworker made this error. Maybe it was just a copy-paste from a website.
  • If English is not a native language of your coworker, it may be a good, or a very bad idea to tell her/him about this mistake. Being from France, I always welcome remarks about the errors I make in English, because it's the only way I can avoid them in future; on the other hand, I know several people who feel really hurt if you tell them about grammar mistakes they make.
  • Like John R. Strohm said, do never do it publicly. Most of the people will be really annoyed by this.
share|improve this answer
"Maybe it was just a copy-paste from a website." Then the person copying it should have caught the problem and fixed it. Copying it verbatim and leaving errors is as bad or worse than writing it themselves and creating the errors. "I know several people who feel really hurt if you tell them about grammar mistakes they make." In business we all should behave as adults and coworkers who are pulling together to accomplish a common goal. The person bringing up the issue needs to use tact, and the person receiving the criticism needs to accept it and grow from it. –  the Tin Man Dec 28 '10 at 7:21
I agree 100% that as professionals, we should behave as adults, and to not take this personally. But it absolutely needs to be pointed out and corrected. Yes, tact should be used, and it should be approached as needed, depending upon the individual. But if you are in an environment where it is encouraged to avoid the issue altogether, maybe it is time to leave. This would point to a poisoned environment. –  Mark Freedman Dec 28 '10 at 13:50

I guess its worth mentioning here that HTTP referrer header in the HTTP protocal was misspelt as referer ( and we have to live with it/ we have learnt to live with it .) :)

share|improve this answer
And we never want to see that sort of thing again. –  David Thornley Dec 28 '10 at 20:54

I do it only if

  • it affects the usage of the program
  • it affects the accuracy of the program
  • I explicitly know the author wants to be corrected.

Just as a side note, if your function names are long enough to have grammar, they're probably too long. In the example given, I would call the function userHasPermission and move the "grammar" into your code, something like this:

if userHasPermission() ...
share|improve this answer
There's still the same potential for grammar mistakes, though, since in this case userHavePermission() would be wrong. –  Dean Harding Dec 28 '10 at 8:44

This also happens A LOT in my project (being populated by natively Hebrew, Russian or Arabic speaking people), but even to a higher level - often I see code that uses some obscure terminology that happens to be what the dictionary produced as the translation for what the author had in mind, and it has nothing to do with the they meant...

Personally, when it happens so frequently and by so many team members that could have wrote the code even before I joined the project, I tend to ignore it, because it just won't matter.

However, if I'm committing some work in the same file as code or comments that have been written long ago and they have typos in the, I will correct them just because it's not too much work.

share|improve this answer

userPermission() perhaps ? -

Last one I came across was a global issue of search results not being highlighted because the classname was spelled hightlight. Very obscure bug to spot.

share|improve this answer

Sure point it out, but don't waste your time checking for spelling mistakes. Use a tool to automate this on your CI. On .net fxCop can do this...

share|improve this answer

Golden Rule Applies

Do unto others as you would have them do unto you.

I want others to have my back on this kind of thing, so I help others. Being gracious and supportive can go a long way in your favor.

share|improve this answer
-1 for vagueness -- I have no idea what you are advising the questioner to do. –  HedgeMage Dec 29 '10 at 18:27
I'm familiar with it. In addition to being patently silly (there's no reason to believe that the way Alice wants to be treated is the way Bob wants to be treated), it distracts from the real issue: creating good code. Sure, I'm not going to be a jerk about it, but I'm not basing whether or not to raise a technical issue on whether or not the person writing bad code wants it raised! –  HedgeMage Dec 29 '10 at 21:21

I would recommend using an IDE with built-in spellchecker. IntelliJ Idea does a wonderful job for Java programs. There are many embarassing typos it catches, not only in names of functions, but in e.g. exception messages the user gets to see. A program that produces messages full of typos does not inspire much confidence.

share|improve this answer

As with many other good programming practices, the only objective, non-political, and effective way to implement a policy about spelling in programs is to automate it as part of the pre-commit process. Automation will save you from enormous amounts of grievance even if you have to write your own tool for the purpose.

share|improve this answer
Many of the most important errors can't be caught automatically. This applies to spelling and grammar too. You could do an automatic check, but the results would have to be equivalent to warnings. This is because spell-checkers produce both false positives (e.g proper nouns) and false negatives (two, too, to). So manual intervention is necessary. –  Matthew Flaschen Dec 28 '10 at 21:38

This is a minor mistake in code, but is a mistake. Treat it like any other mistake that you find. My policy is always to assume that my co workers are competent and treat them that way until they prove otherwise.

If it's a single mistake I might just fix it and check it in. If it's a pattern I might start getting that co worker to review those fixes. Let them know that you think they're a good coder, but that this is something that would be good to improve on. I don't think I'd ever make a big deal about something like this though.

As long as you don't treat it like it's a big issue it should be easy to put that co worker in a position where they can improve without putting ego on the line.

share|improve this answer

It depends largely on what the mistakes are, how common and how bad they are, and whether it's actually a bona fide mistake or just not how you'd word it.

I personally can't stand it when some idiot drags a 5 minute code review out to half an hour because he wants everything renamed to how he'd do it and all the comments reworded just because he likes sticking his oar in. A logging line that says "Loading data objects" does not need to be changed to "The data object loader component will now load the relevant data objects from the data object storage component".

/rant :)

share|improve this answer
Insisting on things my way is one thing. Insisting that things use proper spelling and grammar is another thing entirely. –  David Thornley Dec 28 '10 at 20:54

Your Answer


