Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Jerry Asher writes "Not all of my coworkers are careful about spelling errors. Sometimes this causes real embarrassment as spelling errors creep into software interfaces. Does anyone know of spell checkers for programming languages? I don't want a text spell checker, I want a programming-language-aware spell checker. A spell checker that I can pass all of my code through and will flag spelling errors in function names, variable names, and comments, but will ignore language keywords, language constructs and expressions, and various programming styles (camel code, or underscores, or...). I want a spell checker that knows that void *functionSigniture(char *myRoutine) contains one spelling error. Does anyone have such a thing for Java or C++? Are there any Eclipse plugins that do this?"

The version of Eclipse I run, Eclipse WTP 3.3, does spell checking on comments as standard. Not for variable, function names and the like though. It's a decent first attempt though.
In truth, I turned it off within the first few hours. It underlines any mistakes in red which I find really annoying when scanning code as I keep thinking I've seen syntax errors. More often than not my eyes are drawn to a spelling mistake, which in many cases isn't even really a mistake, which distracts me from what I'm actually trying to look at.

A software engineer in San Jose, CA was found dead at his desk yesterday, apparently having died while waiting for his Java editing program, Eclipse, to finish its boot process. Coworkers say the engineer came in that morning vowing to "get Eclipse working on his box or die trying." The last thing anyone heard him say aloud was the cryptic comment: "I see the splash screen is appropriately blue." Nobody knows what he meant. The man was then thought to have fallen asleep, but hours later it was discovered that the engineer had died suddenly of apparent natural causes. The forensics team's investigation that evening was reportedly interrupted unexpectedly when the dead man's Eclipse program suddenly finished launching. The team tried to interact with it to see if they could find clues about the man's death, but the program was unresponsive and the machine ultimately had to be rebooted. At this time, the police commissioner says there is no evidence of foul play, and they currently believe the man simply died of either boredom or frustration.

Here's one way to ensure an Eclipse launch takes enough time for you to go grocery shopping:

Work in a windows environment in Virginia. Access the Eclipse workspace directory through a mounted drive pointing to your home directory on a UNIX box in Montana. On the UNIX machine, your home directory is actually mounted on a Windows box back in Virginia.

God help you if you have the "compile on save" option enabled. And don't even THINK of rebuilding the workspace.

Spell checkers are fine but they make mistakes as well. The best thing I have found, and this goes for any project, software or printed word, is to have someone who is not connected to the project or better yet not even connected with the subject proofread what the public sees. They will often catch mistakes that jump off the page but people working on the project just don't notice. I have made some really stupid mistakes that I never saw but were on the cover of a book I was publishing. I am SO glad it was

"Any douche who doesn't realise a misspelt function name will fail to compile clearly hasn't written any code yet."

You clearly fail to see a programmer can also create their own function names, as well as use other peoples functions. So you prove you are a very inexperienced programmer, (and close minded), which adds weight to the idea you are either young or just arrogant. Also your very apparent need to show hostility, shows a degree of insecurity, where you are over compensating, by verbally hitting out at others, in an attempt to appear to be more knowledgeable than you really are.

The easiest way to become a better programmer, is to be more open minded. So far you have failed to demonstrate this.

As a side note, (back in the DOS days of programming), I found the the spell checker in Multiedit very useful (especially when having to work very late at night, after the coffee stopped working!;)

More like WTF are you on man?? If a compiler is able to work out what a variable is, what piece of code does what, which bit's of text are going to be displayed, then another spell checking program can be written to recognise this too!! It would be tricky, and there are many circumstances where it could be circumvented but why not still use it to prevent a possible spelling error, and the circumstances where it cannot tell what the word is, so what. Those circumstances you learn to spell but there's nothing

string literals (not what the poster wanted, but this is what needs spelchekars the most)

identifiers

The former can be done by a simple regexp, the latter... you can do a LALR parser, but why even bother? Just look for _any_ potential identifier; in most languages, that's [a-zA-Z_][a-zA-Z_0-9]+; and simply add the few keywords which are not English words to your dictionary. In fact, this would be nearly programming language agnostic.

1. The stop-problem is undecidable only on a device with infinite RAM, if you put an upper bound on the RAM, you get a decidable problem (in theory only).2. There are some practical ways to construct proofs that a loop ends (remember the CS lectures). Sure, it's not a perfect solution, but if you can't construct a proof that the loop ends, you'd better rethink the loop, and possibly rewrite it.

Its impossible for a computer program to be constructed which can do so for all cases (hence, the halting problem), but that doesn't mean that its impossible to detect some infinite loops, or to detect constructs which are particularly likely to be infinite loops, either of which could, in theory, be useful features in an IDE.

Spelling/grammar checkers for human language aren't flawless, either, but they still have uti

It is important to note that with a large code base, Visual Assist is noticing any time you have a variable or function name that it can't find anywhere else, and highlighting it with the red underline. This is in addition to turning the various keywords, macros, #defines, class names, function names, member variable names, nonmember variable names, and other such things all into their own colors. Granted, if you misspell something everywhere, then it will highlight correctly, and not indicate a problem.

See listed spelling features. It will spell check normal language (looks like only comments) and highlight *mistyped* symbols, not mispelled symbols.

Just FWIW, it checks typing in both comments and (perhaps more importantly) string literals. It's also "intelligent" enough to know (for example) that '%d' should not be treated as a problem in a string literal. It is true, however, that symbols that are misspelled don't get highlighted, provided the misspelling is consistent.

Um, let me introduce you to the famous spelling mistake: HTTP Referer [wikipedia.org].
How about we let computers and people each do what they're good at. Computers are good at comparing strings in a spell checker, and people are good at producing typos, spelling mistakes, and approving fixes.
Discipline isn't the solution, better tools are.
(I bet there's a spelling mistake in here -- which proves my point that Opera needs a spell check like Firefox!)

You're aware of the concept that a bug is cheaper to fix the earlier you spot it? If it's flagged up as soon as it happens I have to rename that one variable in one place, and I can do it at virtually no cost. If it's flagged up after I've finished the work and committed it for review, then I'll need to change it across multiple files (sure, an IDE will do refactorings like that in most cases, but there can be side effects) and recommit. That's a far greater expense.

.... that if you want your code to read like english, you consider a language like COBOL? Not that it would help you with spell checking, per se... but if one is going to be so pedantic about making sure that their procedure names can be found in an actual english dictionary why not go the whole 9 yards and write the whole program that way?

if you want your code to read like english, you consider a language like COBOL? Not that it would help you with spell checking, per se...

Responses like this entirely miss the point of the question. Same with the "just review your code" responses. It's not a matter of making the language more readable. It's a matter of making the code more usable. Certainly, correct spelling is pointless without other elements of good code practice. However, bad spelling can add a lot of frustration.

I joined a project which already had a few misspelled class names. I'm a fast typer and often I've typed out more of a filename than is spelled correctly before hitting tab to complete the name. Needless to say, I've been trained to hit tab earlier for a few choice files. But it's certainly been an irritation. Similarly, I've been confounded more than once when a function or variable couldn't be found by the compiler, only to realize that I'd spelled a word correctly rather than how the actual name was spelled.

We choose to use English words for our class, function, and variable names for a reason. That reason is mostly defeated by misspelling the English word. A dictionary is a great idea, even for coding languages that don't "read like English".

It strikes me that the problem is that most spell checkers try to check everything, and that a lot of code has things that really shouldn't be spell checked at all, mixed with things that should. I imagine that one way to start would be to only alert on those errors that are almost correct -- if it looks like garbage, ignore it, but if it's close, assume it should be right. Perhaps ignore prefixes / suffixes as well -- pSomething is fine, pSometihng isn't. Also, CamelCase ought to be easy enough to detect -- treat it as word boundaries, and spell check the individual words. Again, egregious misspellings probably aren't -- nextObjFoo is ok, even though Obj isn't a word -- it's so far from being a word that we assume the programmer meant it that way.

Similarly, there should probably be a set of words added that aren't "English" but are used often enough to be worth adding to the dictionary. Things like Obj, Int, and Ptr.

I think the reason such spell checkers don't exist already is fairly simple -- everyone just assumes they're impossible, and doesn't try. Couple that with the fact that a mediocre quality one would be so annoying as to be worse than useless, and you have a recipe for a program that won't get written. I don't think either of those would have to be the case if someone sufficiently clever decided to attack the problem, though.

Isn't that basically what syntax highlighting does anyway? A simple heuristic for a programming spellchecker would be "Did I highlight it? No? Well I'll spellcheck it, then" with a suitable syntax dictionary and language dictionary. Initially certain words wouldn't show up in the language dictionary, but you'd add "setDictPath" when you define it. A quick bit of code review to make sure that no mis-spelt words get into the dictionary, and you're done.

Anything that may appear in a user Interface should be kept in dedicated files. Use a standard format such as CSV, XML...It may be reviewed by non-technical people with built-in spell checker software such as excel. This is a trick mainly use for multilanguages project, but it really helps.

...which is an interesting problem, but really a different one. If you look at his example, he's talking about botched function names etc. which really is code. User-visible text is usually spellcheckable in whatever format is being used to do translations. And if you hardcode English everywhere, then well... you're probably not interested in this kind of quality-enhancing tools to begin with.That said, I rarely see this as a big problem unless it's a very static internal interface. Pull the whole code tree

The solution to this is simple, you use the Microsoft approach which is to keep old names of the functions around and wrapper them to the new names in the hope that people will start using the new name instead of using the old name. That said it shouldn't have been a problem anyway. I have translators who email me reminding me my English has mistakes from time to time (last one was writeable/writable, writable is supposed to be the right one but both come up as spelling errors in Safari anyway) so having a

I particularly like the spelling feature in new vim, right-click menu (:set mousemodel=popup) to select a corrected word or remember current word as correct. Perhaps writing a vim plugin as you explain could be possible? I'd be very glad to use it too;)

Yep, me too. Especially I like that it is aware of comments and text zones and spell checks them as you write the code. It can also check the spelling of function names, if you use underscore_to_separate_words. As for a code spell checker, it is pretty good.

People here making fun of his request and saying that this should be set in stone in design documents, or be checked in peer code reviews are obviously not working in a run-of-the-mill software company where there's neither the inclination nor the time to do everything the formal way. Also, I have to see the first design document that correctly enumerates all the requirements for the software, let alone all the names for the variables to be used.

As a non-native English speaker, working in a non-native english speaking team (mainly french speaking people) it is a real problem. The biggest problem happens when you search something and don't find it because you wrote it right and your coworker wrote it wrong. (Or the inverse, I don't claim to be perfect in English)

Sure, you might say, "Write your code in French", but that's not a solution. My mother tongue is Dutch, we have a German coworker, and you never know if the next guy will be Italian. There is also this team that has to maintain code written by Spanish people.... in Spanish.... and they don't know Spanish. Fun times, if you like to hear them curse....

I am currently working on a java-based universal spell checker (the kind that can do a decent job without involving knowledge of that language). By language, I mean, English, Hindi etc.I am amused by the idea of being able to extend that to programming languages.The most significant problem that I am facing has nothing to do with coding the spell-checker. Its about getting a sizable dictionary of words (finding one, converting to UTF-8 etc.)

In a normal development shop, you could probably make such word lists on the fly.Just appoint one "spelling guru" who is the only one allowed to edit the list and add new words to it as you go. It's probably better to strictly manage the list anyway, considering the various number of ways some words can be written, i.e. color vs. colour. You'd probably want only one of those variants allowed.You could probably use a simple lexer to detect function and variable names and (customizable) regex to extract the c

I am not sure if you are ignorant or illiterate.exactly when did i say that i code in windows (and if i do, so what?)and are you upset that java is not being released in the BSD license?

I never said that I could not find a dictionary of english words. if you had read my post, you would know that I talked of dictionaries in multiple languages. Of all the languages in the world, English is just one of them. It might help to remember that much.

Okay, so it's only for Managed Assemblies (C#, VB.NET, J#, etc), but it does spell-checking, acronym-checking, and case-checking, which is nifty. Along with the other slew of introspection rules (some of which are a PITA to implement, even if it does increase the quality of the finished product).The $$$ version of Visual Studio (the Team Suite version) comes with an introspection engine for VC++ though, it's not as flexible as FxCop but does the basics.

TextMate on OS X has spell checking functionality that is semi-useful, but it's not really "aggressive" enough, and there doesn't seem to be a way to make it such with prefs/configuration.

You can right-click on any "word" (variable name, subroutine name, whatever, just generally a whitespace-delimited group of characters) and it will check the spelling and present alternatives in the context menu. It also recognizes things like perl's sigils so correcting '$teh' turns into '$the', not 'the'.

It _won't_ automatically check spelling except in strings (so e.g. if I have '$teh = "This is a tset.";', 'tset' will be underlined, '$teh' won't). It doesn't include comments in its automatic checking either, which is probably the most annoying part about it.

Overall I typically just don't bother with it, but someone _has_ thought along these lines, at least.

The idea is nice and I think the problem is really prevalent. I have seen large portions of source code, much of it commercial, containing not one or two but hundreds of spelling mistakes. I also believe the problem must be more prevalent in closed source and in small businesses than open source and Free software. Another thing is that developers from countries with non-English languages often mix English with their first language in code, making it hard to maintain by other nationalities.

Well, I'm a total newbie in terms of compiler architectures and such, but throwing it out there for the purpose of discussion...I assume a compiler will parse the source and in the process identify which tokens are key words and literals, and which are programmer-defined identifiers in the code. The spell checker would either use the same algorithm, or latch into that part of the algorithm to get at all of the identifiers. There are two possible word separators in typical code--either capital letters or u

Yes, this is a legitimate problem. I work on code that has spelling mistakes embedded into interfaces and it's very annoying. The fashionable use of StudlyCaps in programming (why? who decided that TextLikeThis is more readable than text_like_this?) makes the job a little harder but not impossible, as long as you follow the sane rule of making each word start with capital and continue lowercase, even if an acronym (so XmlParser not XMLParser or, God forbid, XMLparser - though of course XML_parser would be better than any of those).

That will give a list of unique words in your source code (use find and xargs to scan the whole source tree). Then you can run that list of words through an ordinary spellchecker such as ispell. Unfortunately when you find a mistake you have to go back and grep for it to find where it occurs. You would also need a personal dictionary for things that are not English words but nonetheless appear in code.

I would probably keep the private word list containing things like 'foreach' and 'const' with the program source code, and have a makefile target 'make spellcheck' that runs a command like the above and then prints out all words found that are not in/usr/share/dict/words or in the private word list. Indeed, why not this:

I suspect that they actually decided that TextLikeThis was easier to type, and sufficiently readable that the typing ease benefit was worth the switch. Of course that's because no one thought of making shift-<space> map to _.

'' It points out spelling mistakes in "strings" but not variable names. ie, it won't point out that the variable lAnsIdx is spelt incorretly, like the submitter is asking for, that would be just stupid. ''Comments like this make me wonder. Is it so hard to imagine a spelling checker for say the C language that finds words that were not written the way they were intended? Limiting yourself to correct English words for identifiers is stupid. Assuming that a spelling checker for a programming language would do

Nothing personal, but it's not actually a programmer's job to make sure everything is speelled correktly. This is part of the QA process before a product rolls out the door. Sure, you should do your best, but you need another pair of eyes (or several pairs of eyes) looking at the UI in addition to your own. You can easily miss the forest for the trees.

I had your problem once because I was working with people whose first language was not english. I don't write US English either and I always left English spellings in by mistake.I used aspell and went through huge parts of the source, telling it what wasn't misspelled. It was an incredible pain in the neck because it got confused over all the variable names, bits of C syntax etc etc.

Once I had a dictionary, though, I could recheck the source periodically and although there were a lot of false warnings, we

True, identifier names containing spelling errors can be a real annoyance, but I somehow doubt you'll ever find a usable solution, at least not as long as you'll need to interface to code beyond your control. What spell checker wouldn't choke on regular C++? Just picking a random declaration from MSDN (feel free to choose any other API, it won't change anything):

This is completely off the top of my head, but do you remember how early C compilers used to only recognize the first six characters of a function name? So, for example, create_foo() and create_bar() were recognized the same way.Now, in essentially every program in the world there is a function named 'create_something' or alternatively 'createSomething'. Had Ken Thompson's creat() function been spelled create(), early C compilers would have treated them the same way, thus making any function starting with

Yep. Programmers should know how to spell correctly in their native language. But hey, all through school those technonerds where likely the same ones who never missed a chance to whine about how they hated their English (or whatever) classes and thought that learning grammar and spelling were a waste of time when they could be doing cool geek stuff. The rise 1337-speak and txtspeak hasn't helped.

At least in the real writing business there are editors trained and paid to catch these errors.

Being unable to spell correctly makes you look really stupid to most people.

Just FYI, if you have a decent programming environment, it should at least flag cases where you've mistyped an existing identifier. If there's an ImmediateFlag in your code, you'd get a warning if you typed ImediateFlag or ImmediateFalg or whatever. Not much help when the programmer is creating new identifiers, of course. Although I've seen cases where the programmer in question for whatever reason decided that because ImediateFlag was undefined then they would just define it, even though ImmediateFlag existed and was what they meant. That ought to get you fired in my book.

Hey by the way, pair programming is a great way to have continuous code reviews and a check on some of the more typical fumble-finger errors.

The question wasn't about user interface strings. It was about spelling in APIs. e.g. One issue at my last company, which was British, is that they standardized on US spelling, but some British spellings crept in too. So sometimes you'd get a function containing "Initialize" and sometimes "Initialise".

It's not so simple when you're not the one writing the code, but have to deal with the results. There's an SDK that I use as a part of my job, developed by our head office in Japan - it's a set of C# classes, and nothing annoys me more than typing "Connection foo = new Connection();", then noticing Visual Studio isn't highlighting it as I'd expect. Hunting around for anywhere up to a minute and eventually finding out it is actually "Conectin" instead of "Connection". If there were a good "programmers spellchecker", I may not need to use it myself, but I could give it to my Japanese colleagues to make MY life easier!
(note: the above example is fictitious, but is an illustration of the type of error that I deal with that this would prevent)

Remember... your code will run faster if you remove some, but not all, vowels from your variable names.To the original question: is strncpy misspelled? What about foo? sqrt? exp? Impl? Programese has an interesting linguistic history and its lexicon contains much not found in English.

While misspelled variable and function names are annoying, a refactor tool and a compile make them relatively painless. Perhaps the best approach would be to take your API documentation, run a script to split CamelCase an

Why don't more software developers take a leaf out of Knuth, who "only proved it correct, not tried it" [grammar]?

Yeah, that's great and all, but this is something you can only do for small algorithms. Proving correctness of large systems takes huge amounts of time and resources, so for most developers this is just not feasible. Also a while ago, someone notable in the Java world (Gafter? Bloch? Can't seem to find the link) blogged about how he had discovered that one of the core textbook examples taught t

Also a while ago, someone notable in the Java world (Gafter? Bloch? Can't seem to find the link) blogged about how he had discovered that one of the core textbook examples taught the last 30 years in the courses about proving code was in fact incorrect...

"nearly all" is an overstatement.The bug is a consequence of integer overflow. Which is a perfectly common type of bug in languages where "int" and thelike overflow. But really, in most cases it's insane to expose messy internal details of the representation and computer to the programmer.

Yes, sometimes you need to. But most of the time you should be using a language and/or library that encapsulates details like that so that you can say "some integer" and have the language and/or library take care of whatev

Well, all that he found was that it is easy to overflow a 32 bit signed int value, which is nothing new. The concept of an array of 2^30+ bytes is what broke this code - recompile the code on a 64 bit platform and it just works, bug free (up until 2^63 arrays, but still..). The fact that 'nobody will ever need more than 2^30 (over 1 billion) array entries' isn't a bug in the software per se, just a bug in the specification.

the key skills of programming, spelling and pretty much any other ability you'll ever attempt to acquire.

In English enumerations, you have a comma before the last and. You should have written:

programming, spelling, and pretty much any other ability

Oh beautiful irony. Now go to a library and pick up a grammar book. Or maybe, just maybe, realize that everyone isn't perfect and that spelling isn't viewed as really important by that many, and that a spellchecker is a really useful tool.

I expect my artists to have spelling mistakes. I expect my coders to know the semantics of a language that they are using. If they don't I question their ability on the semantics of the language the project is coded in.

No, Microsoft's FXCop actually does all of this for.NET. It can be configured to solve all of your examples, I think, through global and per-project custom dictionaries although it does assume CamelCase and will complain if you use too long strings of all CAPS. (But you can turn that warning off.) It does more than spell-checking, e.g. you can tell it to warn when people use "LogIn" and you prefer the term "LogOn".

C++ requires that a parameter passed to a function have a different name from the same class member.