There are competitions on the Internet to write the most egregious and highly functional code fragment in the fewest lines of code. This is particularly easy to do in C language. Certain operators lend themselves to the construction of extremely terse code, which, although functionally very clever, is also very hard to understand when diagnosing faults or carrying out maintenance.

This entry is not to recommend against the use of such operators, but to urge a word of caution on the basis that modern language parsing and execution engines may be smart enough to highly optimize the code, making any performance gains negligible anyway.

These days, it is quite difficult to yield any noticeable performance gains by epitomizing the code at the source level with compiled systems. There may still be some gains to be won with interpreted code. A badly designed algorithm may continue to perform badly in an interpreter where there is a possibility it might get corrected in an optimizing compiler.

The operators to be particularly cautious about are the assignment operators and the prefix/postfix operators. The ternary conditional operator is also hard to read in source and may offer little advantage over an if(...) ... else construct. These are equivalent but intent is much more obvious with the if(...) ... else form:

   // Conditional ternary operator

   myResult = (mySwitch) ? "TRUE VALUE" : "FALSE VALUE" ;

   // Conditional block

   if(mySwitch)

   {

      myResult = "TRUE VALUE";

   }

   else

   {

      myResult = "FALSE VALUE";

   }

Where this causes particular problems is in the maintenance phase where you might perhaps be adding another line of code. In cutting and pasting an existing line, it can be easy to overlook an operator and accidentally increment something twice or assign a value inadvertently.

Special care is necessary with iterators and conditional execution blocks. A particularly nasty habit is to have a condition that when true, executes one statement. This is frequently written into the source text without any enclosing braces. Those braces are important because they group the block of code into a single syntactical unit. When you later try to unpick someone else's script, the indentation may fool you into seeing several lines that appear to be conditionally executed when in fact only one is. The same applies to iterators as well. It is highly recommended that you put in the braces where they are required for multiple line conditional code and iterator blocks even when there is only one line of code being executed. This safeguards against errors when more lines are added to the conditional or iterated code block later on.

This is not recommended practice:

   if(aCondition)

   someCode;

   while(aCondition)

   someCode;

   for( ... )

   someCode;

This is slightly better but requires more effort when adding lines to the code block:

   if(aCondition) someCode;

   while(aCondition) someCode;

   for( ... ) someCode;

This is less dangerous than having no braces but makes the line long and twice as hard to scan visually:

   if(Condition) { someCode }

This is fashionable, but the braces are hard to balance visually:

   if(aCondition) {

   someCode

   }

This is good because it thinks ahead to the possibility of maintenance and tends towards fewer editing errors:

   if(aCondition)

   {

   someCode

   }

   while(aCondition)

   {

   someCode

   }

   for( ... )

   {

someCode

}

If there is any downside to this it is that every balanced pair of braces will create a new execution context. This may slow performance, but on the other hand it can allow locally scoped variables to be created and destroyed at a level that is more granular than a function body.

There is also scope for a religious debate on indentation. Three space characters works great (for me). I don't like tabs because if you move the source code to another editor, the indentation can go awry. Space characters for indentation ensure that the source code looks the same in any monospaced editing window and probably looks OK in a word processor too.