Why good style is important ...

Every now and then we get attacked for "nitpicking" or "worrying about braces" or "complaining about bad data names".

Well, there is a rather fun website "The International Obfuscated C Code Contest" that pokes fun at people who code in an incomprehensible way, by asking for examples of the very worst obscure code ... that actually does something useful.


My personal favourite is jason.c.

Once compiled on a Linux machine (it doesn't work on Arduino because it doesn't have stdin and stdout) and run, you see stuff like this:

you are in a maze of twisty little passages
caves lead:  left forward right back
you see
   a lamp
   a scepter
> take lamp
> get lamp
> get scepter
> f
you climb...
you are in a maze of twisty little passages
caves lead:  left forward right back
> f
you climb...
you are in a maze of twisty little passages
caves lead:  left right back

Well that looks pretty good. A standard Adventure-style game. But the code?

        ;;;s , ra,
     n, d), && C ( j +R( s-j+t( i- 1) )
           )D( W)m[ c* 4| z( j ) ]
        &&_( X )E (d     ( 0
               )&&  R( 6)/ 6
               ? c= 17|_ ( T )
                   , v =i & 3 ^ 2
                   ,+j & 3&&W ( j)||y ( 10 )D (k) --
                   j ? k ( O[j]=R(15 ))
: 1 D
             ( H )o ( 7+! !  i+3 )+


    c=i /4 & 63,
    a= 1


I'm not joking. The whole source file is like that.

For example, further down:

     E (n ;char, 1 ,a,6 ,o ())*  Z[
    E(M [37 * 9 *3 ] ,0,L [ 99] ,3] , * *S=Z ) ;
     E (*p=+1 ,char( m)[6 , co , 4 ],ol)
       V ( v=*O = k( j= 9 )) ;
    return ! c&& - ~ ~ - -! printf
     ( ( "%d \n") , F (P ( 0) +6)            *50 + !  ! b*
      ( +b - (int)time ( 0 )) )
;, (         b= 60 + time ( 0)+ 60 * 4)              ;, n =Y
              (u (s =Y (i) ) )

Nowhere in the source can you see anything like "you are in a maze of twisty little passages". And indeed the entire source is only 3851 bytes.

The point here is, that if someone wrote that and said "I need to change 'maze' to 'cave' - can you help me?" my first response would be: "you need to make the source readable". And with good reason.

The great advantage of that code is that you can’t cheat on the game by looking at the source code. I did something similar when an adventure game was to be published in a magazine for people to type in, remember those days?

Mind you years ago I wrote a program to massage code to make it unreadable.

This was to stop people copying a BASIC program and changing it to make it look like they had written it or even understanding what was going on.

What I did was to have a string of six or eight characters and then replaced all the variable names with this string, making the variable unique by mixing upper and lower case in this string. The result was most unreadable.

Grumpy_Mike: What I did was to have a string of six or eight characters and then replaced all the variable names with this string ...

I thought of trying to obscure code by making every data name some unique combination of lower-case l, 1, 0, o and 0. That should be hard to follow!

Here’s another fun one: night.c (in part):

    ; G AG;                                    G TG;
   G AC;                                      G C; G
  A=0; G AAG; G TT; G GG; G AT(CT A){ GA A%4>>A%4-1
 ; } CT GC(){ AC=!(AAG&(CA/=2)); CTG=15*CA*CA/4; G
 A=TG;                                 GA AC||A&&
 AT(A                               /CA/CA); }
 CT GTCA                          (G C,G A,G
  CG){ GG(C>=A,C)G(!A)GA (C&&CC,CG^TAG); CG
   +=(C<A)<<20; G T=TCT(0,C%16*3-34,302
    [C%16*2+            GTT]); AAA; G(
      CG>TCA)A;      GA CG^GTCA(C+
       3,A-1,CG  ); } G CGAC(CT
          T,G  A,G C,G AA,G
             AG){ GA(AA&&
          (CA=4)&& (   CGAC(
        1+T,1+A,C,  --AA, AG)?
      CGAC(ACG[     T],AG,0,C,A):
     ACG[T]&&TCT(AG,A,ACG[T])),C); }
    CT TGA(G A){ CT T=1; CT C=-T; *AA=A;
   *GT=3;                     G(++C^T){ G(
  (TA=AA                         [C])/2&!(TT
 =(TG=                              GT[C]+16)&
 15))GA TG>>4; CA=4; AAG=TA>>2*TT; A(GC()&&(AA[T
 ]=TA^1<<2*TT<<AT(AAG),GT[T++]=TG^CTG>>AC); )} GA
  0 ; }                                    G ACC(){
  G T=4;                                     G A=1;
   G C=1;                                     TC=TGA
    (GG=CCC); G((A*=2)<C||(C<<=A=1)<T||(T*=C=2)){ G (
      TGA(AG=GG^T^C^A)>TC) { G((TC=TGA(GG=AG))>CAA) {
        CAA=TC; CAT;                            } G (
          TC>>6)GA 1;                          C = 1;
            T=2; } G(1+                       CC) GA
               1; } GA 0; } GAT{ AGT=GCC=GTT; G(T=*
                    ,7&(A+=5))||(      *++AGT=CAA
                       =C=0); ATG   AC(4); G(!
                          ACC   ()); AC(2); G

Grumpy_Mike: Mind you years ago I wrote a program to massage code to make it unreadable.

I think some of the forum posters already try that, like:

digitalWrite (6, HIGH);  // make pin 8 low

:) Yes and when you tell them they are most put out, "well I changed the code but not the comment" is the usual reply. The other one is "but it compiles so there is nothing wrong with it".

[quote author=Nick Gammon link=topic=97894.msg734227#msg734227 date=1332414030]

digitalWrite (6, HIGH);  // make pin 8 low


That's a good example of where it's better to not have a comment.

[quote author=Nick Gammon link=topic=97894.msg734227#msg734227 date=1332414030]

digitalWrite (6, HIGH);  // make pin 8 low


Nice one. :-)

I used to love those obfuscated C contests, never entered one but some of my code probably would have qualified.

When C++ first came out I wrote a program that IIRC was something like

include "i.h"

int i; main () {};

All the code was in the int constructor :)


My personal favorite C/C++ source code, that, while not obfuscated, is nevertheless fairly unreadable - is something that one would -think- would be readable, since it was source released by an actual software company.

That would be the source code for Descent (old DOS 6DOF 3D shooter).

Now, I have never worked for a game development company, so maybe things are done differently at them (which might explain some things?). But when I started in my career as a software developer, I was taught to properly organise and comment my code, to use meaningful variable names when possible, and to stick with a convention to naming variables (as well as a set coding style). All of this was so that other coders could work on the same code; if all worked with the same set of rules and style, then (in theory) any coder could pick up any other's work, and continue work on it.

When the sourcecode to Descent was released, I downloaded it and looked thru it, to see what I could see. Some of the stuff I was familiar with, and could understand it from a code perspective, but even then - it was still a fairly jumbled mess; variables were not well defined, sometimes function names were obscure, there was hardly any commenting, and what little there was in many cases didn't seem to give much more of a clue as to what the code was doing. There were some really intricate parts to this code, too - being a portal 3D engine and such.

Now - a bit a source code in the same genre that is much more readable?: Quake - I was pleasantly surprised. It must just be the company, and the development culture within. I'm not sure why some companies don't want to have readable code (maybe they're concerned about corporate espionage or something?) - but that's the way it is...

On a different note, we've all seen (or some of us have) Perl scripting that shows where it gets it's moniker of "line noise"; generally in my experience this comes from extremely heavy reliance on the part of the programmer in the use of regex expressions for any kind of filtering or string manipulation. There do exist, however, examples of "beautiful" Perl script; well commented, consistent variable naming conventions, and anything obscure put away in a reused function (and sometimes commented well enough to understand what that function does, provided it isn't obvious). Again, I don't understand why all coders don't follow these conventions (it could be argued in the case of an interpreted language inlining everything would result in code that is faster running than function call with push/pops on the stack - but this should only be done as a last optimization resort, instead of "pre-optimizing" something that doesn't need to be critical in that manner in the first place, until you know after testing).

Some of it has to be education (or lack of it), in that they haven't been exposed properly to these conventions and good coding practices; what stinks about it, though, is that many times they leave behind messes that others end up having to "clean up" (or, more likely, scrap and rewrite - because of course what is generally found is not only lack of comments, and poorly organized code, but also the fact that there was no overall development plan or system documentation developed in the course of development - in some cases, not even an operations manual for the client).

Perl, language from hell :slight_smile:

They don’t have obfuscated code competitions because you couldn’t tell the difference between the entries and all the other Perl code in the world.


I tried to teach myself Perl once. After all, it's pretty popular. But after working through some of the early examples I was saying "what?" ... "they do what?".


One of my favorites.

I did write a guestbook system for my web site in Perl, thank God I moved to an ISP that supported PHP so I could ditch the lot.


Regarding Perl - this is the example I was thinking of; it's what got me interested in learning Perl, and served as a great example as to how you could write clear and easily maintainable Perl, without everything looking like "line-noise" from tons of regex:


...unfortunately, it really seems to be the exception, rather than the rule.


Think you know C?
Google “Duff’s Device” ]:smiley:

+1 for speed. -10 for obscurity.



+0 for speed, -1 for obscurity

ah and +5 for coolness factor :)

AWOL: Think you know C? Google "Duff's Device" ]:D

I love Duff's Device. The first time you see it, you scratch your head. The second time you see it you cry because you can't understand it. The 50th time you see it you cry tears of joy because you finally understand the damn thing...and its beautiful.

On another note, not even the most obfuscated C around can top anything written in brainfuck. Someone ought to write an arduino brainfuck interpreter. EDIT: I've found my project for the last days of March Break! Time to get brain$@%$&#*ed.