how to find out if spelling mistakes in source code are a serious issue or not? [closed]

Question

I find very troubling amount of spelling mistakes I see everyday in our codebase, from which I will reproduce a very short but representative example:

ArgumnetCount
Timeount
Gor message from queue 

Unfortunately this is in no way limited to one person. There is a lot of non-native English speakers in our team who contribute to that, however I can also pinpoint some of the worst spelling mistakes to our Software Architect who is American, born and raised.

These are also to be found even in emails, presentations, documents, whatever piece of written information we have in a software development company.

I'd like to know how to find out if it is a serious issue or not?

_{I've always met these spelling mistakes with concern, but my own, personal, official policy is that we are not paid to spell things right, we are paid to get things done, so inside the company I never really criticized anyone about it. But I have raised this issue with some of my close friends, and never settled it for good.}

Answer 1

Spelling errors can mean one of two things:

• The person who makes them is not proficient in English, and doesn't take the time to compensate by using appropriate tools (dictionaries, spell checkers, etc.)
• The person who makes them is proficient in English, but doesn't care about spelling at all.

Either is a fairly bad sign, because it means the person in question doesn't have readability, maintainability and elegance high on their priority list; if the cause is a lack of English language proficience, it also means that the person lacks two essential skills - written English communication, and a general feeling for languages (if you can't express your thoughts clearly in English, chances are you can't express them well in a programming language either).

But why exactly are spelling errors bad, all else being equal? After all, the code works, and the compiler doesn't care at all how you name your identifiers, as long as they don't violate the syntax rules. The reason is that we write code not only for computers, but also and most of all, for humans. If that weren't the case, we'd still be using assembly. Source code is written once, but read hundreds of times during its lifecycle. Spelling errors make reading and understanding the source code harder - mild errors cause the reader to stumble for a fraction of a second, many of them can cause considerable delays; really bad errors can render source code completely unreadable. There is another issue, which is that most of the code you write will be referred to by other code, and that code more often than not is written by someone else. If you misspell your identifiers, someone else will have to remember (or look up) not only what the name is, but also how exactly it is misspelled. This takes time and breaks the programming flow; and since most code gets touched more than once in maintenance, each spelling error causes a whole lot of interruptions.

Consider how developer time equals salary equals expenses, I think it should be easy enough to make a case of this; after all, breaking the flow and getting back into it can take up to 15 minutes. This way, a severe spelling error can easily cost a few hundred dollars in further development and maintenance (but they're indirect costs, not directly visible in estimates and evaluations, so they often get ignored by management).

Answer 2

The first time you waste time searching for the Timeout variable just to find out it was written as Timeount, you'll know another reason why spelling is important.

Answer 3

I actually doubt whether "Timeount" is a matter of not being a native speaker. People make tons of typos in their first language. I wouldn't qualify these particular examples as "Engrish".

Having said that, I understand that it's not about these particular examples. I agree with you in principle. I've come across actual troubles caused by this type of stuff ("if there's no column named attachements, create attachments").

Being a programmer is about being precise and careful with typos, commas, semicolons, dots, which is human-language-agnostic most of the time.

Answer 4

If this issue bothers you, most IDE now allow spell checking in comments so that dyslexics can at least look like they know how to spell. It sure helps me! It is therefore a trivial "fix" to have good spelling.

Answer 5

Spelling errors in public class names and methods are simply unprofessional. They cost time and money. They are painful in statically typed languages like Java, where the IDE can produce a menu of class and method names. They are intolerable in dynamically typed languages.

Even worse are spelling errors in database table names and column names.

In my experience, correct spelling is only slightly related to the coder's English proficiency. I have seen native English speakers produce code with essentially random spelling and word breaks, and have seen non-native English speakers who are careful to produce correct spellings. But correct spelling is highly related to the overall code quality. Capable programmers, no matter their English proficiency, care about the quality of their work, and are careful with naming.

Answer 6

In source code, internal presentations and documents etc. small typos that don't alter the meaning or hamper understanding are not a porblem. Just fix them in the source yourself if you find them irritating.

Also, particularly in comments, the substance is more important than the form. No Engrish here:

String s = "Wikipedia"; /* Assigns the value "Wikipedia" to the variable s. */

The fact is that some people are naturally more careful writers than some others (whether this is due to education, or due to attitude, or due to intelligence or whatever, is not relevant). How much to spend effort to fix that is a business value question: do you get more value from fixing the typos, than you spend effort in fixing them? In case of internal stuff, the answer is usually no. Your customers aren't going to complain about typos in your source code comments (unless you're doing open source).

Intentional mis-typing and inappropriate comments are unprofessional and should be avoided, but the focus should be in things that matter (i.e. generate business value, if you work for business).

Publicly visible stuff must of course be carefully proof-read.

Answer 7

The problem here is not the engrish itself but the lack of comment clarity. Perfect english isn't necessary, clear English is. Its trivial to run something through google to pick up the obvious errors.

For example its not clear from first glance if Gor message from queue means "got a message from the queue" or "GOR message from queue". You would need to read the code to understand the meaning of the comment (thus defeating the object of the comment).

You should ask to implement code reviews in your company. You can then "criticize" people in a constructive way while they do the same to you.

Answer 8

It should be obvious that the compiler doesn't care about misspellings, as long as you're using the same spelling, e.g. when referencing a variable. The question then becomes whether misspellings have a negative impact on the ability of team members to maintain the code.

The only way I can see to do that would be to talk to the people doing the maintenance, and you could start by asking if anyone had a harder time following code that contained misspellings.

I don't think there's any way to remove subjectivity from this issue completely, but to reduce it, you could (manually or through a script) scan the source to get an estimated number of misspellings for a particular code module, and see if maintenance on the modules with a higher number of misspellings took more time on average than those modules with fewer misspellings.

Not all modules are made equal of course, so you could think about weighting your results with various metrics such as the cyclomatic complexity of the module.

Answer 9

In my experience such basic spelling errors are troubling, and may be symptomatic of deeper problems. Every project I've worked on with "trivial" errors like that had real problems in design that somehow made it through the review process only to crop up during development, which is not when you want to find out that the critical functionality you really need isn't there.

I'd double-check the specs for the system (if they exist) and examine the overall design; I wouldn't be surprised if you found some holes.

Answer 10

This is actually two separate, but related issues. It depends on where the misspellings are:

1) In source code. If you have an identifier like ArgumnetCount, that can create real problems when someone comes along and uses the correct spelling. So you should fix those mistakes whenever possible. If you need to preserve backwards API compatibility, you can do something like:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) In human-readable text (emails, documentation, code comments). Writing those correctly is important, but I would say it's a lower priority, since the parsing software inside your head is a lot more forgiving. If you see a text with a few mistakes, that's still readable, then don't worry about it - it's not your problem. But if someone sends you some free-associative nonsense and expects you to use that nonsense as the blueprint for a multi-user web application, then you should send the author a polite note requesting clarification (something like: "You illiterate moron, how do you expect me to understand this shit?")

Answer 11

Correct spelled english is a must in code. I also have a large codebase full of gibberish in it and it's a nightmare to maintain.

Don't let this get out of hand. Try to educate everyone that the code maintainers are not mind readers.

Answer 12

Well, this is a many-sided cultural problem.

Speaking from a german perspective: we notice how our own language gets more and more influenced by english terms. This goes so far as national companies having english slogans or advertising. Some people, especially in management positions are meanwhile apparently unable to utter but one sentence in plain german. Their speech is full of buzz words and incomprehensible management slang. We say such persons are speaking "denglish".

Given this state of affairs and English being the "lingua franca" especially in software business, it is unavoidable that English itself is influenced by the vast number of non-native speakers. But for English native speakers this is still better than having to lern, say, Chinese in order to take part in the SW industry.

Answer 13

Is it colour or color? Whose version of English do you think is the correct one? One mans correct spelling is another mans excuse to start an winnable war.

If you want to start a war, pick your battles carefully and win them. In your case, don't worry about comments, worry less about internals and focus (almost) exclusively on API's

Answer 14

I have a maxim: Tidy code does not necessarily mean a tidy mind, but the obverse is certainly true: untidy code, untidy mind.

A programmer who doesn't take the time to name variables correctly and spell comments correctly is almost certainly not taking the time to do anything else correctly. Whether the programmer is a native English speaker is not a real issue, since issues with his English can (and should) be addressed during peer review.

Yes, it is a serious issue for the product, for the team and for the individuals.

• For the product: correction may introduce defects which are only caught by customers
• For the team: the team spends time fixing sloppy coding rather than creating value
• For the individuals: bad spelling makes you look stupid and lowers your professional standing among your peers.