A horrifying piece of C code

Zhan

L5: Dapper Member
Dec 18, 2010
208
244
This is something a close friend of mine wrote the other day:

Code:
[FONT="Courier New"]char p,q,r,w[151];
int main(int c,char**v){
  int _=151;
  r=2^c?0:atoi(v[1]);
  while(--_>0)
    w[_]=_==75;
  while(_++<40&&puts(""))
    for(p=c=0;c<150|(q=w[c]);putchar((p=q)?35:32))
      w[c]=r&(p?240:15)&(w[c]?204:51)&(w[++c]?170:85);
}[/FONT]

Believe it or not, it actually prints out 1D elementary cellular automata, and takes the cellular automata rule as the first command line argument. If any of you have a C compiler, you can run it with 90 as the first argument and it will print out a nice Sierpinski triangle.

Those of you with programming experience: I apologize for any loss of sanity.
 
Sep 12, 2008
1,272
1,141
phah! I can!

Code:
dflwjshd kgfljfhg kjwfhg klwjhgl kjfgh<jhg $G HJKFGH WLKJGHL lfjkh 
gw jfghlkfjgh kljhaz a jhg aekjhga emgjh oifhj klfhjflmk jh
 

Zeewier

L9: Fashionable Member
Sep 20, 2008
619
262
phah! I can!

Code:
dflwjshd kgfljfhg kjwfhg klwjhgl kjfgh<jhg $G HJKFGH WLKJGHL lfjkh 
gw jfghlkfjgh kljhaz a jhg aekjhga emgjh oifhj klfhjflmk jh

That "code" could indeed be turned into a fractal :p

Ontopic:

You should tell him to comment any code that he writes.
 

Zhan

L5: Dapper Member
Dec 18, 2010
208
244
You should tell him to comment any code that he writes.

Oh, he does when he writing normal code, he's a very competent programmer and writes good code. This was really just an experiment to see how obfuscated and abusive of C constructs he could make the program.
 

TMP

Ancient Pyro Main
aa
Aug 11, 2008
947
560
Huh?

This code isn't THAT hard to understand.

Now if he had made it in the shape of a horse.....
 

Zeewier

L9: Fashionable Member
Sep 20, 2008
619
262
It's about habits, also when you look back to your code weeks later it's easier to see how you have done things.

Also: The new trend is that more and more people within a company have to understand your code, even if they are not the programmers.
 

Zhan

L5: Dapper Member
Dec 18, 2010
208
244
It's about habits, also when you look back to your code weeks later it's easier to see how you have done things.

Of course, of course. Both of us have interned for a tech company writing code, and we're both familiar with the marks of good programming practice.

This piece of code is a sort of joke, and is not to be taken seriously.
 
Feb 14, 2008
1,051
931
It looks harder than it is because he's obfuscated all the if statements using that annoying shorthand I don't completely understand. It's nice and compact, if entirely unreadable, and not good practice in general. :(

I've been advised you should never comment inside a method, it just makes things more confusing and messy. Comment at the top of every method and the top of every class - no more is necessary unless your code is absolutely terribly complex (in which case you should make it less so). I have to say, this works rather well.
 
Last edited:

cyked

L3: Member
Dec 18, 2009
132
89
Rand's right. It's mostly just obfuscated code. the pre/post increments arent too hard to follow. I still dont know why he chose "_" as a variable other than to be a dick and then that only leaves the shorthanded if statements which like rand said are just confusing for most people (i dont really mind them) although his code would've made more sense if it started like

Code:
int _=151;
char p,q,r,w[_];
int main(int c,char**v){
//REST OF PROGRAM BLARGHHH
}

edit: I dont remember if you can use a variable to initialize an array in c++! either way, it makes more sense to define the int outside of main with the rest of the variables anyways
 

Terr

Cranky Coder
aa
Jul 31, 2009
1,590
410
I've been advised you should never comment inside a method

I disagree: The comments that explain how code implementation works need to be as near as possible to the lines that actually do whatever-it-is. Comments on methods should describe what they do to the level-of-detail required by the the caller, while comments inside the method describe everything else.