C++ style question/criticism, was Re: Mozy Contest Answers

[Levi Pearson]

On Nov 4, 2006, at 9:13 PM, Dave Smith wrote:
> I thought it looked better aesthetically, and I learned how to use  
> my editor more effectively (vim). I used to keep as much code on a  
> screen as possible, so I could refer back without scrolling (I'll  
> call it "optimized for vertical compression"). Then I learned how  
> to use vim. Between vim's m, ctrl+p, %, *,  #, n, and N, I can move  
> around in code without regard to white space or vertical  
> compression. Also, I've fond ctags and cscope useful when working  
> with others' code, but I rarely use them on my own. That's been my  
> experience. I let the editor do the grunt work, and I lay out the  
> code however I think it looks best, even if that means sacrificing  
> a few rows of terminal space.

My vim-fu has become weak since I started programming in Lisp with  
emacs, so I only recall what % does off the top of my head.  There's  
that memory thing again.

Even with fancy editor navigation, you simply get more context when  
things are reasonably compact.  Jumping around in the code via editor  
magic is just as distracting as scrolling is.  It's like a context  
switch for the visual cortex.  The more clear meaning that can fit  
within visual range on a screen, the more meaning can be absorbed in  
context before movement must take place.

Braces mean nothing to C and nothing to humans by themselves; they  
are simply punctuation.  We don't give English punctuation its own  
lines; we don't even give our most frequently used punctuation marks  
a full letter's width of space.  That's because they're a secondary  
informational cue and not meant to be consciously noticed.  We convey  
meaning to other humans in our words in English, and with keywords,  
functions, and operators in C.  By concentrating on how those  
semantic elements fit in relation to one another on a screen instead  
of the semantically void punctuation, we can get a lot more meaning  
from a given visual space.

This is one thing that became very clear to me as I learned Lisp.   
It's a very punctuation-heavy language, yet the punctuation is almost  
never considered by the humans who read the code.  Meaning is  
conveyed to humans through indentation and positioning of semantic  
elements, and the punctuation is fit in secondarily to that in as  
compact a form as possible, so it can be ignored.

For example:

(defun foo (a b)
   (let ((c 3)
         (d 4))
     (if (a > b)
         (+ a c d)
         (+ b c d))))

This is roughly equivalent to:

int foo(int a, int b) {
   int c = 3;
   int d = 4;

   if (a > b)
     return a + c + d;
   else
     return b + c + d;
}

You can see how the close-parentheses just build up on the end of the  
last line of Lisp.  You may think this is ugly at first, but it is  
done because the parentheses are just punctuation, and Lispers just  
don't look at them.  Giving them each their own line would be  
ridiculous, since the function would take a huge amount of space to  
say exactly the same thing, and would be less clear to boot since the  
information would be spread further from the center of the visual space.

		--Levi