Multithreaded Musings
Stand back - I'm a scientist!
Archives
« November 2009
MonTueWedThuFriSatSun
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
      
Today
Click me to subscribe
Search

About Me
Known throughout Sun as a man of infinite wit, of jovial attitude, and of making things up about himself at the slightest whim.
Links
 

Today's Page Hits: 34

« ZFS Everywhere? | Main | Happy St George's... »
Wednesday Apr 18, 2007
Clarity vs. Conciseness

The instinct is always very strong to make code as compact as possible. There's something satisfying about squishing code down from, say, 20 lines to 15. And yet, there's often a trade-off involved. There are several ways of optimizing code: for space, for speed, for memory usage, and so on. Each has its own benefits and costs. Another way, which can actually be detrimental, is to optimize for source size.

Consider this code, whose logic is similar to something I just wrote:

     found = 0;
     for (i = 0; i < count; i++) {
          if (array[i] == item) {
               found = 1;
               break;
          }
     }
     return (found);

For each element of the array, compare it to the item; flag (and break) when found; return whether we've found it. Very straightforward. But we can eliminate the i variable and save some stack space. The trade-off is code clarity:

     found = 0;
     while (count--) {
          if (array[count] == item) {
               found = 1;
               break;
          }
     }
     return (found);

The semantics have changed slightly — we're now searching from the end of the array rather than from the beginning — but the effect is the same. It's slightly harder to read, though. Poor John Q. Maintainer has to sit there and work out the post-decrement logic with the array indexing. It'll finally 'click', but it'll take longer than the first version of the code.

Of course, we could save a couple more lines, and another variable, by tossing away found like this:

     while (count--) {
          if (array[count] == item) {
               break;
          }
     }
     return (count >= 0);

If it took a minute or two extra for Mr Maintainer earlier, this will probably add more time to his quest. Not only does he need to work out what count is doing in the loop, but he's got to determine what count could be after the loop is over, and what that means for the return value.

Throwing in a comment would help:

     while (count--) {
          if (array[count] == item) {
               break;
          }
     }

     /* count is >= 0 if item is in array[] */
     return (count >= 0);

Too bad comments aren't more widely used; maybe it's because writing them makes the source code size bigger! The version of this loop I actually used was the second form, in an attempt to choose a balance between clarity and conciseness. Feel free to tell me I'm mistaken.

Posted at 03:42AM Apr 18, 2007 by Mark Musante in Coding  |  Comments[1]

Comments:

Shorter code is usually easier to understand, particularly when it's in a large function (and we have plenty of those; even though long functions are supposed to be bad, it's often difficult to avoid), where having to scroll back and forth to understand it can be obnoxious. In the case of a code snippet like you show this is really not a big deal: it's trivial to add a short comment that says "search array for item," but even that's not needed for a common idiom. A complex math/logic expression relying on rounding semantics, for example, definitely needs a comment.

Posted by Nico on April 18, 2007 at 04:35 PM BST #

Post a Comment:
Comments are closed for this entry.