The DiffMerge snippet in the previous section also illustrates another principle of writing for comprehensibility: code that is alike looks alike. We see this throughout the DiffMerge code. For example:
while( d.diffs == DD_CONF && ( bf->end != bf->Lines( ) || lf1->end != lf1->Lines( ) || lf2->end != lf2->Lines( ) ) )
The preceding demonstrates how line breaks can create a visual pattern that makes it easier for our brains to recognize a logical pattern. We can tell at a glance that three of the four tests in this while statement are essentially the same.
Here's one more example of alike looking alike. This one illustrates coding that lets our brains do a successful "one of these is not the same" operation:
case MS_BASE: /* dumping the original */
if( selbits = selbitTab[ DL_BASE ][ diffDiff ] )
{
readFile = bf;
readFile->SeekLine( bf->start );
state = MS_LEG1;
break;
}
case MS_LEG1: /* dumping leg1 */
if( selbits = selbitTab[ DL_LEG1 ][ diffDiff ] )
{
readFile = lf1;
readFile->SeekLine( lf1->start );
state = MS_LEG2;
break;
}
case MS_LEG2: /* dumping leg2 */
if( selbits = selbitTab[ DL_LEG2 ][ diffDiff ] )
{
readFile = lf2;
readFile->SeekLine( lf2->start );
}
state = MS_DIFFDIFF;
break;
Even if you don't know what this code is about, it's clear to see, for example, that readfile and state are set in all three cases, but only in the third case is state set unconditionally. The programmer who wrote this paid attention to making alike look alike; those of us reading it later can see at a glance where the essential logic is.