The "Conversation" of Computer Science: How Grice's Maxims Make You a Better Coder

Grice’s maxims are an excellent way to try and make sense of how speakers and listeners convey information efficiently and reliably. Does this apply to all languages? Like, say, the Java programming language?  For those who have taken CS classes here, you know how much lecturers and section leaders emphasize “style,” which is following unwritten rules of sorts so others can read your code easily, an industry-must that allows others to go and interpret your code later for maintenance or adding features. Thus, the “speaker” will be the person writing the code, and the “listener” is the person interpreting the code. That being said, how can we relate Grice’s maxims to CS?

Maxims of Quality: How do you lie in code? It’s quite simple really. As a programmer, it’s your responsibility to write names of methods and variables that relate to their actual functionality. For example, if you were to write:

            //This adds one to a number and returns it

public int addOne(int number) {
     int newNumber = number + 2;
     return newNumber;
}

This clearly adds two to a number, not one, thus blatantly lying to the “listener.” Thus, good style is to always put relevant and truthful function names and comments.

Maxim of Relevance: This one can be much more subtle and interesting. Let’s start off with the “while” loop and the “for” loop. The while loop goes on until a condition is met:

            while(conditionIsMet == false) {
                doStuff();
            }

The while loop doesn’t stop until the condition is met hypothetically, and who knows how long that will be. A “for” loop, on the other hand, has a preset number of iterations. For example:

for (int i = 0; i < 5; i++) {
    doStuff();
}

will loop exactly five times. Now, if I wanted an infinite loop, the common way to do this is like:

while(true) {
    doStuff();
}

Another way to do this same thing is like:

for (;;) {
    doStuff() ;
}

The maxim of relevance allows people to make inferences by a particular “utterance.” Using the while loop is relevant as it tells the listener that the loop does not have a preset iteration value. However, using the “for” loop is not relevant as it is not used for its intended purpose, making the “conversation” harder and making the code much harder to interpret, especially for much more complicated algorithms.

Maxims of Quantity: This one actually gets broken all the time. Not naming variables as informative as required can make an interpreter’s job very difficult. Look at the following code:

            int variable1 = doSomething();
            int variable2 = doSomethingElse(variable1);
            int variable3 = handleStuff(variable2, variable1);

What does it do? It’s not lying, as in those methods probably do, in fact, “do something” and “handle stuff,” and those variables are, in fact, variables. But the amount of information is not as informative as required to let the reader know what is going on in the code, making it much harder to follow the "conversation."

Maxims of Manner: Look at the following code:

            int x = 3, y = 5;
            int xor, and, temp;
            and = x & y;
            xor = x ^ y;
            while (and != 0) {
                and <<=1;
                temp = xor ^ and;
                and &= xor;
                xor = temp;
            }
            int result = xor;

Do you have any idea what this does? What if gave you this instead:

            int result = 3 * 5;

Both of these do the same exact thing! The second piece avoids ambiguity, avoids obscurity of expression, is brief and is very orderly compared to the first. The first actually isn’t a violation of quantity because the first piece is “too wordy” as opposed to “giving too much information,” since both pieces give the “same amount of information,” or do the same task. Likewise, the first piece also uses methods that are difficult to understand when there is a much easier way to get this result.

These were all extreme examples, but they illustrate my point. Programmers often make more subtle violations of these maxims, and when it becomes a habit, it makes it incredibly difficult to interpret one’s code, just like bad speaking habits can make it difficult to listen to a speaker. Good “style” in coding is important, and treating programming like a conversation can have such a positive effect on how readable your code is for others.

Followup question: I also thought of a couple of examples of “flouting” maxims in CS, but I ran out of space in my blog. Any ideas about this? Any more examples? Agree or disagree?