The International Obfuscated C Code Contest (IOCCC) has now posted the winning entries from its 25th event. The summary of winning entries does NOT contain brief explanations of each winning entry, so you can try to spot the tricks yourself. If you don't mind seeing a brief summary of each entry, there is an alternate page with spoilers linked to from the main page.
The goals of the IOCCC are to write the most Obscure/Obfuscated C program within the contest's rules, while showing the importance of programming style, in an ironic way. It stresses the C compilers with unusual code and illustrates some of the subtleties of the C language. Lastly it provides a safe forum for poor C code.
(Score: 4, Funny) by The Mighty Buzzard on Monday May 07 2018, @04:23PM (8 children)
Most all of my C is naturally obfuscated. Sometimes I'm so good at it that even I can't read it the very next day.
My rights don't end where your fear begins.
(Score: 2) by bob_super on Monday May 07 2018, @05:30PM (6 children)
I've actually had to threaten to fire a guy who used acronyms for all his variables, and never wrote a line of comment. His stuff was working, but was unmaintainable, maybe not even by him.
He was nice enough to find somewhere else to be.
(Score: 0) by Anonymous Coward on Monday May 07 2018, @06:15PM (1 child)
Gotta save those bytes man!
I have never found typing speed to be the bottle neck, so I try and keep my variables reasonably descriptive.
(Score: 1) by redneckmother on Monday May 07 2018, @06:36PM
(See a porting project description below)
I'm not much of a typist (school of seek and ye shall find), so I employ "search and replace" to improve function / procedure / variable / parameter names... I usually start out with some funky short string as a name, then s/r to a descriptive one. Sheesh, modern editors - who'd a thunk it?
After much wailing and gnashing of teeth, I converted a coworker to using the same technique - he had been partial to using variable / parameter names like "j1", "j2", etc. for both locals and globals. He also gained appreciation for documentation in comments. Oftentimes, comments explaining intent are helpful for identifying logic and coding errors.
Mas cerveza por favor.
(Score: 4, Interesting) by redneckmother on Monday May 07 2018, @06:21PM (3 children)
Used to develop in assembly language - had a hard time deciphering some x86 source for a port to another device. The x86 author was steadfastly opposed to using comments, and was fond of saying, "Well, it's obvious what this routine does." Hell, even the name of the routine didn't come close to hinting the intent. The original source was heavily hand- optimized for both size and instruction cycle counts, sometimes using obscure register "side effects". Don't miss trying follow that dick's crap.
The target device was proprietary, and the ported application was tested nightly (in Japan) during the project. The testers were VERY thorough, albeit not fluent in English ("Step 1: Press space key 512 time" ... "Step 49: Press Enter" ... "Error is occurred"). They uncovered some GLARING logic errors that existed in the x86 code, which I had faithfully ported. The lesson I learned is that, no matter how good the pay, a functional port from well documented code is a MUCH preferred task. And yes, I commented the crap out of my port.
Mas cerveza por favor.
(Score: 0, Disagree) by Anonymous Coward on Monday May 07 2018, @06:53PM (1 child)
Not possible.
(Score: 0) by Anonymous Coward on Monday May 07 2018, @07:14PM
Yes, it is. Less opcodes means (usually) less clock cycles.
(Score: 2) by jb on Tuesday May 08 2018, @07:26AM
I've never understood that attitude.
Surely assembly language (for any given target architecture) has got to be the language that encourages comments more than any other. After all, isn't that why the instructions are all so short -- so there's room left over for a comment on every line?
The same held true even back when 40-column displays were a thing -- with 80+ cols to play with, there's really no excuse...
On the other hand, I feel your pain with deciphering x86 code. That's one instruction set that seems to have been designed to discourage readability (which only makes good comments even more important...).
(Score: 2) by RS3 on Tuesday May 08 2018, @01:02AM
There's too much artificially obfuscated C. It's heartwarming that you're greening up the code and getting back to nature.