Why you need linguistic skills – part 1

Language in dictionary by Christian Grass @iStockphoto

While writing code may seem very logic-based and technical in nature, your skill in human languages is equally important. Why else would Visual Basic read like English? In this series of articles, I’m going to talk about why improving your linguistic skills make you a better programmer.

Broaden your mind

A limited range of vocabulary restricts your imagination. Part of imagination requires you to describe something. The more words you can use for describing, the more vivid, the more exact and the more complete the object of description becomes.

As a programmer, you have to translate business logic, task requirements and given instructions into code. The better your grasp of language, the better you’re able to imagine the final product, and thus the better you’ll be able to visualise the code and write it. What it comes down to is you must understand something that someone else wrote. You need to know the nuances of your language of choice because that someone may have wanted one thing, but actually wrote something else.

For example, in one of my user task requests, there was this requirement about entering random input. Based on the business context and the web form that was to support this feature, I deciphered it as being able to enter any range and any number of input in a specific format. I checked with the user, and it was indeed that way. Sometimes users lie, unwittingly perhaps, and in this case, using the wrong words to describe what he wanted.

Give it a name

What’s the one thing you do every time you code that requires linguistic skills? Name your variables. Every time you declare a variable, you make a conscious choice on what that variable’s fate in the ensuing code is. Every time you name a variable, you make a conscious choice on what is required of the variable.

There’s a concept I read in a fantasy story by David Eddings, and it goes like

Know the name of an object, and you gain power over the object

Yet some programmers are lousy at naming variables. Some programmers don’t care about the variable names. I bet some programmers even hate naming variables. Why else would there be names such as “a”, “b”, “c”, “DataGrid1”, “DataGrid2” and “Table1”?

Of course, there are perfectly rational decisions on using certain names. Variables in loops are usually single letters, and they are usually “i”, “j” and “k”. That’s probably a 3-level nested for loop in the making. I’ve gone up to “l”, “m” and even “n” before (matrix manipulations. Fun).

Based on context, you can easily know what those loop variables are used for. And that’s the important point, the context in which a variable is used. A simple “dt” for manipulating dates and times in a small and well-defined section of code is ok. But if there’s no context, can you tell what the variable is used for?

“It’s compiled into an executable anyway. Besides, there’s the search function,” you say.

Of course, tools such as Lutz Roeder’s Reflector make it easy to obtain code. You can use the search function to find where a variable is used and thus gain an understanding of its purpose. “t1″s and “t2″s don’t bother you at all.

Writing code is in the same spirit as writing a sestina, or writing a letter, or writing a business document. You are writing to be understood. And until artificial intelligence improves, you’re writing to be understood by a human.

The compiler might understand what you wrote (or not, depending on how bad a programmer you are). But you’re really writing for a human being. Someone is going to use that application you wrote, and they’d better know what it does. Someone is going to maintain your code, and they’d better understand what it does.

I can understand the difficulty faced by my Chinese reports (stationed in China), whom I pass some programming tasks. English isn’t their native tongue. The specification documents need to be written in easy, simple language for them to understand the business logic. Before any French or German programmers hammer me with protests, I want to point out the importance of the language used in the communication. Again, it’s about context. If your users use English and your documents are in English, your code had better be easily read in English.

Obfuscated code is hard to read because the context is taken out, be it requirements, indentation, spacing or addition of superfluous stuff. To add and support context around code, you need a certain level of linguistic proficiency (yes, basic spelling and grammar counts).

So my conclusion with bad variable names is that they arise out of a combination of:

  • Limited vocabulary range
  • Lack of imagination
  • Plain laziness

What’s your excuse for bad variable naming?

  1. Aaron

    I also think that programming can help develop your linguistic skills. I study French and the grammar is my favourite part, as it’s almost like programming. For example, when working with pronouns I use this formula – subject + object pronoun + verb and things like that.

  2. Vincent Tan

    Oh yes, programming forces me to focus more on the grammar and syntax of the (programming) language. Once I took note of those, I took better note of them in human languages such as English, Chinese and even Japanese.

  3. Ben Barden

    I have no excuse for bad variable naming because I don’t do it.

    So, you’re a Visual Basic programmer? Same here, although I do PHP as well. In a lot of the code I’m working on, I’ve seen things like this:

    Dim a, b, c
    Dim x

    Not only are those variables badly named, they’re not even given a type. I’m tasked with rewriting a lot of code so I can address stuff like this, but the code is often very hard to understand.

    Personally, I like naming variables and I also use prefixes. e.g. intCommentCount, strDataPrefix, dteBirthDate. I still have issues with a few names though, as sometimes you end up with two very similar variable names or some very long variable names. It depends on the context, of course, but there is always a variable I have difficulty naming.

  4. Vincent Tan

    My programming roots started with C actually. My first job required me to learn VB.NET, and so I did. The Visual Basic (.NET) code then was, uh, primitive, so yes, I do see some untyped variables here and there. Deciphering code became more exciting while I had to decipher what variable type I’m investigating too…

    “but there is always a variable I have difficulty naming”
    This variable inevitably ends up with a long name… 🙂

  5. Ben Barden

    Ah OK. I’m still on VB6, haven’t really delved into VB.NET yet as our entire codebase is pre-.NET. Some is even in VB3. It’ll take ages to get it all to VB6, let alone any further. Still, I like a challenge! 🙂

  6. Vincent Tan

    Ahhh… legacy code. I’ve had lots of fun before. Don’t miss the late nights and hair pulling though…

Comments are closed.