The pasta theory of code
I don’t know why, but most new programmers I’ve been talking to never heard of spaghetti code. Wikipedia has a nice definition for it:
Spaghetti code is a pejorative term for source code that has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other “unstructured” branching constructs. It is named such because program flow tends to look like a bowl of spaghetti, i.e. twisted and tangled.
Now, there is a whole theory of pasta and code. Spaghetti code is at the bottom. Next comes lasagna code. Lasagna code is made in layers, which is nice, but each layer is quite large and to change the things below you may have to move all the layers above, and you have to follow a very strict hierarchy, which sometimes make it impossible for one layer to talk to another one that is not immediately above or below.
Lasagna trumps Monday.
Even better is ravioli code. It comes in small pieces easy to chew, it’s easy to move parts of it around.
My personal favorite is cannelloni code. It is even better than ravioli code, because it’s neatly organized, but still flexible. It’s very easy to subdivide if some part gets too big, and you can change parts without touching anything else. The filling is hidden and you only see the interface :)
Beautiful code
Sometimes beauty is about contents.
Many years ago I read a story, but as much as I looked around the net for it again now that I’m writing this, I could not find it. I don’t even know whether it is true or apocryphal, but let’s go. If you know anything about the story, please contact me.
There was a composer (IIRC, one of the Bachs) who was teaching composition to a student. The student, who was just starting and seemed to have no talent at all, brought a new composition, which was left on the piano (or harpsichord, if it was really one of the Bachs) at the end of the lesson. A friend of the composer, arriving to visit him, sees the sheet and immediately says: “What kind of crap are you playing?” Just by glancing at the sheet he could tell it was bad music.
#define q [v+a] #define c b[1] #define O 1 q #define o 0 q #define r(v,a\ )v<0&&( v*=-1, a*=-1); #define p(v,m, s,w)*c==*#v?2 q\ <m?(c++ ,d=1,3 q=0,5 q=m,main\ (a+3,b) ,o=o*s q,O=O* w q):0: static d,v[99 ];main (int a, char**b ){d=7; if(*c?! (p(+,3 ,4 q+O* 3,4)p( -,(o?3 :(O=1,6 )),4 q -O*3,4) p(*,4,3 ,4)p(/ ,5,4,3) p((),d, 0+3,0+ 04)*c== ')'?2 q <02?(c ++,0):0 :(o=012 *o+*c- '0',c++ ,O=1)): 2 q?3- 2:printf( "%d/%d" "\n",o ,O))return 1;d=a,r (o,d)r (O,d)3 q =o<O?(4 q=o,O) :(4 q=O, o);r(d, o)a+=3;O? 1:(O=1,2 q=1);while (2 q=o%1 q)a++;v[d]/=O;d[ v+1]/=O;return main(d,b);}No, that is not what I meant when I said “indent it beautifully”. (Credit: Code from IOCCC 2006)
Over the years I noticed a very high correlation between “beautiful code” and “good code”. Just by glancing at source code I can immediately tell its overall quality. Good developers take a lot of care to make code look good: they indent it well and consistently, use a lot of spaces, add javadoc-style comments to every method (and to classes, too, and to fields), add comments explaining logical code blocks (the next few lines do this). It’s also helpful to read the code later — particularly when it’s complex. IOCCC entries are phenomenal code: they are often really smart. But they are unreadable (and that’s the point), and hence they are useless in practice.
I agree that code by itself is not beautiful, but the difference between a mess such as above and a clean, well indented code is obvious. And my theory is that great programmers write pretty code because they are meticulous. They are paying attention to every detail of the code they are writing, so it is a natural consequence to make every character as it should be. They care about the code.
