Prefix notation for function parameters

Abstract

After a lot of gradual experimentation over many years, I recently came up with a streamlined new notation scheme for identifiers in source code. 

In this notation scheme, function parameters get one-character lower-case prefixes that specify not datatypes but the direction of information flow, as follows:

iXXX	= input parameter
oXXX	= output parameter
uXXX	= update parameter = input + output

The prefixes i,o,u are used only for function parameters.  ("Functions" of course includes member functions of a class.)  All other identifiers have to begin with a letter other than lower-case i,o,u. 

Therefore, any identifier used inside a function that does not begin with i,o,u is not a function parameter but a local variable, or a class member variable (or a global item like a global function). 

This notation makes it easy to spot at one glance the most important aspects of the information flow design of the function (both of its interface and of its implementation code). 

Rationale

The point of this i,o,u prefix notation is that it shows (documents), in a very compact way, the direction of information flow that the programmer intends in his design.  This is, unfortunately, something that C/C++ syntax does not allow or require the programmer to specify explicitly in the code (for example, whether an int* parameter is intended as an output or as an update parameter).  (This is unfortunate because it would allow the compiler to catch a greater amount of logical errors.) 

Intended use is different from the actual use of a function parameter in the actual code.  Some of the significant cases where the two are different are:

• When there is a logical error in the code (e.g. when an update parameter is only read or only written, but not both read and written);
• When the code in the function body is not yet complete (e.g. a stub function that leaves an update parameter unmodified);
• When in a set of functions which for genericity purposes must have the same signature (e.g. implementations of an interface class), not all functions actually use all parameters exactly in the typical way (e.g. some implementations may not need to read the original value of an update parameter). 

Syntax highlighting

Syntax highlighting is no substitute for this kind of prefix notation, because syntax analysis can only detect the actual use, and not the use that is intended by the programmer's design. 

(It would be quite feasible, even if somewhat challenging, to write a syntax highlighter that detects from the way the function parameter is used inside the function body whether it is actually used as an input, output, or update parameter. — Although this can only show the actual use, and not the intended use, I think that nevertheless this would in itself be a very useful functionality in a syntax highlighter.)