Do I sacrifice shorter variable names for longer "columned" code?

Question

I am an amateur programer in a CS class trying to learn proper programming skills. This is how my code looks, the edges of it extends to 103 columns.

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }

Before I had those super long variable names I had thing like i, j, k, but my professor insists that we are not to use variables like that in the "professional world" and that even shortened variables like lenWord are insufficient because people might assume it stands for "Lennard's World Literature". He says to choose meaningful variable names but by doing so I feel like I've broken the Golden Rule of coding to keep it under 80 columns. How do I get around this?

Answer 1

Normally when I see code posted here like yours, I edit it, because we hate horizontal scroll. But since that's part of your question, I'll show you the edit here:

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
}

That break may be surprising, but it's more readable than the version with horizontal scroll, and it's better than shortening the names to i, j, and k.

It's not that you should never use i, j, and k. Those are fine names when indexing 3 nested for loops. But here the names are really my only clue about what you expected to be happening. Especially since this code doesn't actually do anything.

Best rule to follow on variable name length is scope. The longer a variable lives, the more fellow variables its name has to compete with. The name CandiedOrange is unique on stack exchange. If we were in a chat, you might just call me "Candy". But right now, you're in a scope where that name could be confused with Candide, Candy Chiu, or Candyfloss. So the longer the scope, the longer the name should be. The shorter the scope, the shorter the name can be.

Line length should never dictate name length. If you feel like it is then find a different way to lay out your code. We have many tools to help you do that.

One of the first things I look for is needless noise to get rid of. Unfortunately this example doesn't do anything, so it's all needless noise. I need something to work with so first let's make it do something.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
    return cipherColumn;
}

There, now it does something.

Now that it does something, I can see what I can get rid of. This length stuff isn't even used. This continue doesn't do anything either.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Let's make some minor white space tweaks, because we live in a world of source control and it's nice when the only reason a line gets reported as changed is because it's doing something different, not because part of it had to line up in a column.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Yeah, I know it's slightly less readable but otherwise you'll drive people crazy who use vdiff tools to detect changes.

Now let's fix these silly line breaks that we have because we're trying to stay under line length limits.

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

There, now the logic in the loop is focused on what changes in the loop. In fact, everything except cipherColumn could be marked final. And hey! Look at that. We now have room to do it.

All I did was add 3 more variables, rename one, and rearrange them a little. And the result just happened to make the lines short enough to fit without a silly linebreak on !=.

Sure the names key and keyNext are not that descriptive, but they each only get used once, don't live that long, and most importantly aren't doing anything that interesting in the loop. So they don't need to be. By introducing extra variables we now have room to make their names long if we need to. Things change, so eventually we may need to. If we do, it's nice that we have breathing room.

I also took the liberty of showing you Jeff Grigg's form 6 variant style of laying out input parameters to respect line length restrictions.

Answer 2

Others have already made some useful suggestions, let me summarize:

• 80 characters per line might have been a golden rule in the 80s. Nowadays most people agree that 100 to 130 characters are fine.
• Use linebreaks inside your expressions.
• Split lengthy expressions by introducing intermediate results.

I like to add another recommendation: Don't be dogmatic about long names! The larger the scope of a variable is, the more information has to be put into its name. And generally it is a good idea to keep the scope of variables small.

For example, if you have a variable for the column of your keyword encryption table and it is clear that there is only this one table used in the scope of your variable, it is fine to call it column or even col. If the scope is larger and there are multiple tables involved, it makes sense to call it keyWordEncryptionTableColumn.

Another example: If you have a loop with a body spanning two or three lines and have to use an index for accessing elements of an array, there is nothing wrong with calling the index i. In this context it is much more readable (for most people at least) than, say arrayIndexOfMyVerySpecialDataSet.

Answer 3

I generally agree with you teacher. However, if you have a variable that you are going to use a lot in a faily large piece of code, it can be better to use a shorthand form for it after being explicit about its meaning. Like when you have a lot of complex arithmetic expressions and assignments, those do not read that well with long variable names.

About outlining:

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388]) 

This serves no purpose, just limiting the line length does not make it more readable. If you want this to be readable, do this:

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

And then you may even want to align type identifiers (add a space after int ). However, be careful/restrictive with outlining initalizations or argument lists like this:

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

The trouble is when you change a name or add a variable, you may have to reformat the whole block to maintain the pretty look. It isn't for the work as much as for the meaningless changes you would introduce, it would look horrible in a version control system. Your co-worker would see you changed the file and do a diff with the prior version to see what you did. Then every line would light up as changed, obscuring the real change. It would depend a bit on the quality of the comparing tool used how bad this would actually be but in general it is not a good idea to make the code too personal and/or have the formatting of one line depend on the other.

Sometimes outlining can serve a purpose, if you have tens of consecutive lines that are almost the same it will be easy to spot where they are different if you outline them.

Note that a workplace may have some automated formatting going on that will just eradicate any fancy formatting you do to your code before submitting it to the version control system.

Answer 4

A lot of stylistic conventions (not rules!) sprung up over the years due to limitations in programming environments. Back in punch-card days, you had a hard limit on the number of characters that could appear on a physical source line (which was why Fortran reserved column 6 for line-continuation characters). It wasn't that many decades ago that I was working on an 80x24 amber-on-black VT220 terminal; while the editors I used didn't limit lines to 80 characters, life was just a lot easier if you did your best to avoid horizontal scrolling.

Under older versions of Fortran (up to '77, IINM), you couldn't even have identifers that were more than 6 to 8 characters long. Even as late as the '80s, C would only guarantee that the first 8 characters in external names were meaningful (which is why some library functions have wonderfully descriptive names like strpbrk).

Of course, two decades into the 21st century, we don't have those limits anymore. There's no reason not to use more descriptive identifiers.

The thing is, in the right contexts, i and j and k are perfectly reasonable, meaningful names. If I'm iterating through an array or a vector in a loop and I just need something to identify the current element, i works perfectly well. I wouldn't use a name like currentElement - it isn't any more meaningful in that context, and it just adds visual clutter.

Having said that, your teacher isn't wrong in forcing you to think in terms of longer, more descriptive names for everything - life will be easier for you if you get into that habit first, and then learn where to economize as necessary. As someone who was at one time forced to fit everything into 8 characters or less, it's definitely better to err on the side of more information than less. As you gain more experience, you'll learn where you can economize on identifier length, and where you need to be a bit more descriptive.

Answer 5

Disclaimer: I'm exaggerating a bit here to make my point clearer. So take any superlative with a grain of salt.

Your teacher is 100% right: There is no "golden rule" about 80 characters anymore (unless you are writing linux code, that is). That rule was established because of the size of the terminals at the time, but nowadays, you easily cram over 150 characters in your enditor window. And even if you exceed that limit, your editor will hopefully soft-wrap the line so you don't have to scroll. And the only reason to not go beyond 80 characters was the need of scrolling.

That said, there is indeed a need not to let your lines grow indefinitely. The longer the line, the harder it becomes for a human to parse. But short variable names are not the remedy for the long lines issue.

The remedy is to split your expressions logically by introducing even more properly named variables. Do not try to be clever with whitespace. Just identify any subexpression that can be aptly named, and create a variable for it. That simplifies both the code calculating the variable, and the code using that variable.

---

Not a part of your question, but I'd like to comment on it anyway: It is a very bad idea to vertically align your = operators.

There are three reasons for that:

1. Editing a block containing vertically alligned operators is a PITA. Whenever the length of the largest variable changes (rename, addition, deletion), you need to retouch all lines in the block to get your "nice" layout back again.

   Of course, this problem may be reduced a bit by using a competent editor, so it's the minor reason. The real reason is the second:

2. Those spurious whitespace changes introduced by realigning don't play nicely with modern version control systems like git. They tend to create significant amounts of merge conflicts where no real conflict has happened, and where no conflict would be signaled if the alignment were not used. Each of these spurious conflicts will cost you valuable time for nothing.

3. The alignment carries zero semantical meaning. It's pointless. There is nothing that you can understand better with the alignment. Every line in your block needs to read by itself to understand what it does, the connection to the lines above and below is of purely syntactical nature.

Since the alignment does not carry any semantical meaning, but produces significant costs, you should unlearn the habit before it costs you any more time.

---

If you like the 80 character limit so much, try some fortran programming. True, the newer standards have raised the fortran line limit to 132 characters, but it remains in effect as ever crippling the compilation of any program that exceeds the limit. If you are any good at programming, you will soon come to hate fortran, including its line length limit. After that, you will be healed for the rest of your life.

I have myself had to do some fortran programming professionally, and I tell you, it has taught me to hate that line length limit most dearly. There is absolutely nothing more frustrating than having to split an otherwise simple and readable line into parts just because the compiler won't compile it correctly anymore. And there are definitely lines of code which are most simple when they are expressed as a single line.

Answer 6

I'm not sure if this works for c or not but is there a way to split formulas across multiple lines? I know something like that exists for python.

See if you can start + (rowSize*nextWord) + nextWord]) { on a new line. (Like press enter in your IDE and see if it indents it so C know's that the previous expression is being completed on the current line)