How C# Spell Check Helps Your Team and Your Code

If you didn’t know that C# spell check was a thing, it is. ?For one thing, you can run a normal spelling analysis on any comments in your code. ?That shouldn’t surprise. ?But you can also check the code itself for spelling errors.

That may seem like a strange thing at first. ?Wouldn’t a C# spell check get pretty weird on anything but single word tokens? ?I mean, if you look up ToString in the dictionary, you come up empty. ?Well, it turns out that you can solve the problem more easily than you might think. ?The same conventions that keep us sane with multi-word tokens, camel case, and Pascal case allow us to break them into conceptual sentences and spell out the individual words. ?Do that and then add some clever heuristics to the results, and you get a surprisingly effective way to separate signal from noise when finding spelling mistakes.

C# Spell Check Offers More Than Cosmetic Help

You might recall the internet meme suggesting that the ordering of letters doesn’t matter terribly for sentence comprehension. ?While life turns out to be a little more complicated, it still leads you to wonder whether the occasional misspelling really matters in the grand scheme of things — especially with something like writing code. ?After all, you’re looking to build a web app, not publish in the New York Times.

And that’s fair. ?Your apps will run just as well regardless of spelling errors in comments, variables, and class names. ?Your end users will likely never see these mistakes, let alone care about them.

Yet in spite of that, spell checking your code helps. ?It helps your team and it helps the quality of your code, and it does so in non-trivial ways.

Not Everyone Speaks Native English

First, let’s look at how a C# spell check can help your team members. ?Land a few programming jobs, and you’ll learn something about our industry: it’s an extremely global game. ?Teams will consist of people from a variety of countries and continents, speaking a variety of languages. ?And that’s assuming your team co-locates. ?Many teams these days work remotely from all over the world. ?Suffice it to say that you will almost certainly have non-native speaker teammates.

Now take that and add to it the fact that English is really, really hard to learn?because of all of the odd rules, exceptions, and one-offs. ?For instance, if you’re taught by a teacher, why aren’t you “praught” by a preacher? ?This confuses non-native speakers. ?Now imagine their further confusion if you typed “praught” somewhere by mistake. ?They’d conclude that this word existed.

This confusion makes life hard for them, obviously. ?But it makes things harder for the team as well. ?Non-native speakers will see spelling mistakes, think them accurate, and then confuse their meanings. ?You’ll find yourself talking about domain concepts represented by the code and meaning different things.

Discourage Cryptic Encoding Schemes

If you think adding misspellings to the mix complicates things for non-native speakers, consider the effects of having a complex encoding scheme for naming things. ?For instance, think of Systems Hungarian notation. ?Years ago, I can remember having (C++) variables with names like lptcstr_appver. ?You did this to bake all sorts of information about the type into the variable name but without all of the effort to type long_pointer_to_a_constant_t_character_string_application_version.

These days, Systems Hungarian notation has fallen by the wayside for a variety of reasons. ?Strongly typed languages and sophisticated code editing tools/IDEs have made this sort of encoding utterly superfluous and, frankly, detrimental. ?If you know what these names mean, they simply become redundant noise. ?But if you haven’t seen such an encoding scheme before, you’ll find yourself more confused than a non-native English speaker saying, “i before e except after c or when sounding like…”

Enabling spell check on your code discourages this sort of practice. ?The spell checker will fight you tooth and nail if you try to bake programming language information into the names of tokens in your code. ?And rightfully so.

Discourage Acronyms

In a sense, we can think of encoding schemes as a specific case of a more general concept: acronym shorthand. ?But I believe acronyms worth calling out separately here.

Just as in other areas of life, you see acronyms all the time in code. ?Usually, these happen not as vestigial encoding schemes but as shorthand for technical or domain concepts. ?Technical procedure specification report becomes TPS report. ?TPS report, in turn, becomes TR. ?And then you name a method something like GenerateTRs.

You know what that means as you write it. ?But can the rest of your team infer it from context? ?After all, acronyms are inherently reductionist. ?TPS report has an obvious path to shortening, but there’s no obvious path back from TR to TPS report. ?TR could mean transfer reference, transport reduction, or just truck for all anyone reading knows. ?People on your team need to scrutinize your code and make inferences. ?And people new to your team? ?Forget it. ?They’ll have no idea and will have to come ask you.

Spell check will ding you for baking acronyms into names because it doesn’t know how to read these, nor does it know how to differentiate them when breaking up a camel/Pascal case token. ?Your spell check discourages you from using acronyms. ?And that’s a good thing.

No-Nonsense Names and Pronounceable Terms

We can generalize once again. ?Weird encoding schemes are a specific case of acronyms. ?And mysterious acronyms are a weird case of unpronounceable nonsense.

What do I mean by unpronounceable nonsense? ?Have you ever seen variable names that seemed to be ripped straight from the list of bad passwords?

• int aaaa = 12;
• string foobar = “whatever”;
• var asdf = GetConnection();

You get the idea. ?Sometimes, in a hurry and at a loss for what to call the thing, developers do things like this. ?And while I understand the predicament, I consider this a terrible practice. ?Luckily, your spell checker calls things like this out and discourages them.

And that brings me to an important, generalized concern. ?The C# spell check discourages abbreviations and nonsense in favor of actual English words. ?And when you’re dealing with actual words, everyone knows their meaning and how to pronounce them. ?This, in turn, encourages collaboration rather than discourages it.

Imagine having a question about some code and getting a coworker on the phone to ask a question about the application version variable. ?Now imagine doing the same about “lptcstr_appver” when you don’t understand the abbreviation. ?You can’t even?say that, let alone comprehend it. ?This discourages collaboration and it makes it harder for the team to reason collectively about the code. ?They become less efficient.

Makes Search Much Better

Speaking of efficiency, think about how you understand and search codebases. ?Maybe you want to understand how the codebase on the whole deals with customer invoice processing. ?So you do something like a text search for “customerInvoice,” reasoning that this will at least give you a good starting point for classes that deal with this.

That works well enough, but you’ll lose out on that one class where someone named the field “customerInvoiec” by mistake. ?Oops.

But this gets worse. ?What if you’re doing more than just browsing to understand? ?What if someone employed some serious copy, paste, and adjust-to-taste programming? ?And what if one of those adjustments involved the aforementioned misspelling? ?When you go to fix a bug that got pasted everywhere, you’re going to miss the fix in the class with the misspelling. ?Getting that name consistent via the C# spell check can help your team’s effectiveness a great deal.

It’s Really Easy, Too

I’m old enough to remember the early days of spell checkers in word processors. ?Lambasted at the time for not catching everything, they nevertheless represented a quantum leap forward in written word accuracy. ?It wasn’t so much that they delivered perfectly spelled prose. ?Rather, they democratized mostly correct prose. ?Before their advent, getting your spelling right meant either being a great speller with a keen eye for proofreading or paying someone to be that for you. ?No longer. ?Even amateurs could produce documents with few misspellings relatively quickly.

The same thing applies for a C# spell check — or for any programming spell check. ?It won’t fix all of your problems, and it won’t make your code perfect. ?But it’s so easily doable and at your fingertips that it has absolutely no downside. ?You can realize the improvements I’ve talked about here with no more effort than it takes you to turn on spell check in MS Word or in your browser. ?Your investment will be so minimal that earning a return on it will be inevitable.

Learn more about GhostDoc’s truly source code spell checker and eliminate embarrassing typos in your apps and documentation before you ship them.

About the author

Erik Dietrich

Website

I am Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.

This author does not have any more posts.