We can't write expressive code

Ever since there are programming languages, good programmers have tried to write code that is expressive enough to be understood and maintained. However, put two good programmers face to face and chances are they might agree on what expressive mean but they won’t agree on how to do it.

Some think that less is better and prefer to use a language whose syntax is compact, preferably a functional language or similar. Some think that the temptation to write one-liners (or punches in the good o’ days of GFA Basic…) being too strong, the code will be compact but not readable.

Some think that comments are very important. Like Jef Raskin who would write its code embedded into a standard text processor (1). Some think that comments are by nature out of sync with the code, so dangerous, and prefer unit tests to express code behavior.

Some prefer to write long procedures you can read linearly, some prefer lots of classes and methods, some prefer OO/Aspect/Ioc/(any buzzword) oriented programming, some think this is dangerous dark magic that changes the code in your back.

Some think that code structure should be treated like GUIs structure, following the same rules to make it quickly usable by new developers. Some think that this is a lost crusade since programming languages tend to not follow Jef Raskin’s Monotony of design rule: there should be only one way to accomplish a certain task in an application.

I think that it’s impossible to write code that is understandable by every developer, even if you focus only on good developers. Every communication between human beings is ambiguous by nature.

We understood this some times ago about written specifications but not yet for written code. Understanding a piece of code is so linked to the context it is presented to you, to your knowledge of the programming language, to your level of expertise in this language…

(1) Programmers at Work: Interviews With 19 Programmers Who Shaped the Computer Industry