While reviewing a co-worker'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 by noticing these?

  • 3
    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. Commented Dec 28, 2010 at 11:12
  • 37
    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.
    – user4626
    Commented Dec 28, 2010 at 12:29
  • 10
    @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. Commented Dec 28, 2010 at 13:09
  • 4
    @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. Commented Dec 28, 2010 at 13:47
  • 11
    HTTP-Referer bothers me often. en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_term_referer Commented Dec 28, 2010 at 19:26

15 Answers 15


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.

  • 7
    +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
    Commented Dec 28, 2010 at 6:26
  • 21
    +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
    Commented Dec 28, 2010 at 15:40
  • 9
    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... Commented Dec 28, 2010 at 20:17
  • 2
    @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
    Commented Dec 28, 2010 at 21:01
  • 2
    @John Bode, I think you should have created a wrapper function :) C# has a neat trick for that (I forgot its name though).
    – Job
    Commented Dec 29, 2010 at 16:40

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.


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.

  • 13
    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
    Commented Dec 28, 2010 at 5:19
  • 5
    @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. Commented Dec 28, 2010 at 5:31
  • 13
    @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
    Commented Dec 28, 2010 at 5:37
  • 6
    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. Commented Dec 28, 2010 at 5:56
  • 6
    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... Commented Dec 28, 2010 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 :)

  • 6
    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. Commented Dec 28, 2010 at 15:14
  • 1
    If you're worried that a fix to any piece of code might break "someone else's" code, and you have no way of telling, then you have bigger problems than spelling. Commented Sep 30, 2015 at 11:56
  • @CornelMasson: Not really. This is a key part of designing an API. Commented Jan 4, 2016 at 1:48

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.


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

  • 10
    And we never want to see that sort of thing again. Commented Dec 28, 2010 at 20:54

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.
  • 12
    "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. Commented Dec 28, 2010 at 7:21
  • 3
    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. Commented Dec 28, 2010 at 13:50
  • Any spelling error can be checked by a simple google search
    – JoelFan
    Commented Dec 28, 2010 at 20:56
  • If someone feels hurt when you point out grammar mistakes to them, they should be hurt. If they have dyslexia, they should tell you. In that case I will fix mistakes quietly; pointing it out would be unnecessary.
    – gnasher729
    Commented Jan 24, 2020 at 8:50

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.


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() ...
  • 1
    There's still the same potential for grammar mistakes, though, since in this case userHavePermission() would be wrong. Commented Dec 28, 2010 at 8:44
  • But that's exactly the point!! userHasPermission() implies that it returns a bool because of the grammar ~ OR ~ it could mean that it sets user permission. (Officer has the bridge :: user has permission). It's still vague. Commented Dec 28, 2010 at 14:23
  • While I agree that the example names in the Q are unnecessarily long, I caution about the "too long" generalization. In this case, the concept can be expressed in fewer words, so it should be shorter. However, what is "too long"? Is there a character or word limit? Commented Aug 8, 2016 at 15:07
  • DoesUserHavePermission adds nothing if value compared to userHasPermission. On the other hand, userPermission is unclear.
    – gnasher729
    Commented Jan 24, 2020 at 8:48

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.


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.

  • 2
    -1 for vagueness -- I have no idea what you are advising the questioner to do.
    – HedgeMage
    Commented Dec 29, 2010 at 18:27
  • @HedgeMage, I am advising the OP to apply en.wikipedia.org/wiki/The_Golden_Rule
    – kevpie
    Commented Dec 29, 2010 at 19:59
  • 2
    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
    Commented Dec 29, 2010 at 21:21
  • I think @HedgeMage's complaint can be illustrated like this: I want code to be the highest quality allowed by the time and resources available, because I care about the project and my future work on it. Bob wants to avoid criticism for correctable mistakes, because he doesn't take criticism well. We will implement the "golden rule" quite differently. Commented Jan 12, 2014 at 4:46
  • The advice means that the OP operates how he would want to be treated. Not to treat Bob how Bob would want to be treated. I was encouraging the OP to correct Bob as he (the OP) would want to be corrected for the same errors, specifically in the context the OP has shared.
    – kevpie
    Commented Jan 13, 2014 at 5:04

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.


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...


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 :)

  • 2
    Insisting on things my way is one thing. Insisting that things use proper spelling and grammar is another thing entirely. Commented Dec 28, 2010 at 20:54
  • Not entirely sure why my answer merits a downvote but nevermind... Also, where did my reply to David's comment go? Anyway, 100% correct English grammar is not always desirable in development. In my above example, "Loading data objects" is not a complete sentence, but it's the more preferable wording of the two - concise, easy to localise and doesn't take up a lot of space.
    – JohnL
    Commented Dec 29, 2010 at 14:00

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.

  • 4
    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. Commented Dec 28, 2010 at 21:38
  • That sort of automation doesn't solve these problems, it just catches some of the mistakes that people make.
    – overstood
    Commented Dec 28, 2010 at 22:54
  • 1
    Autocorrect??? There are plenty of examples of autocorrect "fails" on the internet. That's definitely not good.
    – Florian F
    Commented Jan 4, 2016 at 2:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.