Don’t worry about the title, this is a post about software design. This week I started following a Coursera course, Think Again: How to Reason and Argue. In it, the cooperative principle and its constituting maxims are presented which describe how people ideally should interact with each other. I realized the maxims apply to software design as well; after all, programming is a cooperative process, at least if you want your code to be usable by others. At the very minimum all of the maxims apply to the comments and documentation, them being language. Sometimes a direct relation to the existing design principles we follow can be drawn.
Maxim of Quantity
- Make your contribution as informative as is required (for the current
purposes of the exchange). - Do not make your contribution more informative than is required.
Point 1 boils down to stating everything relevant to the current situation without leaving out any important details.
public class Machine
{
bool _enabled;
public void Enable() { _enabled = true; }
public void Disable() { _enabled = false; }
}
This code leaves out important information, namely the state of the machine. This should be publicly visible.
public class Machine
{
public bool Enabled { get; private set; }
public void Enable() { _enabled = true; }
public void Disable() { _enabled = false; }
}
Point 2 states you should only show the relevant information. This reflects the concept of information hiding which states internal logic should be encapsulated and only a stable interface should be exposed.
Maxim of Quality
- Do not say what you believe to be false.
- Do not say that for which you lack adequate evidence.
Point 1 simply states, “do not lie”. Now you might wonder how to lie when programming, but the following is an all too common example.
try
{
DangerousOperation();
}
catch ( Exception ) {}
Obviously this exception hasn’t been handled. Testing your software gives you the necessary evidence that your code works for the provided use cases, addressing point 2.
Maxim of Relation
- Be relevant!
Within linguistics, being irrelevant can for example mean changing the subject when answering a question. Although possibly a long stretch, the Seperation of Concerns principle states a computer program should be separated into distinct features overlapping as little as possible. The notion of cohesion refers to the degree to which elements of a module belong together. High cohesion relates to being relevant, letting a module only perform those tasks related to each other.
Maxim of Manner
- Avoid obscurity of expression.
- Avoid ambiguity.
- Be brief.
- Be orderly.
Being brief means conveying something as concise as possible. Well, for starters don’t repeat yourself! Your interfaces/APIs should be unambiguous and as clear as possible. There are many examples of this, but here’s two.
class Controller { ... } // Obscure.
public int GetWeight() { ... } // Ambiguous.
Lastly, be orderly. Don’t place everything in one namespace, and code consistently. Follow the conventions in your current work environment, as this will lead to the least surprises.
Programming is very much a linguistic act and thus we could probably learn a thing or two from linguistics and social sciences in general.
Programs must be written for people to read, and only incidentally for machines to execute. – Abelson & Sussman, Structure and Interpretation of Computer Programs
whatheco.de 
I just found a highly relevant PhD thesis which also seems to link up software development to Linguistics! Defining linguistic antipatterns towards the improvement of source code quality