@yog-sohoth: I don't view it as a waste of time, as the article points out, the winners are incredibly talented programmers and if this content is used as a teaching tool (which we plan do to at our event next year) it's an extremely powerful way to learn: By seeing how NOT to do things and why. Plus, we'll teach programmers techniques for fixing poorly written code, which I'm sure we've all run into at some point in our careers!!!
@kfield: If you teach people how to write obfuscated code just for fun, chances they will use it one day - maybe they are being taken off a project, maybe they are getting fired, who knows?
Now if you teach them how NOT to do things, but how to do them better and more cleanly, then I am 100% in agreement.
I have seen some code where a subsequent maintainer added the comment 'the f*****r who wrote this should be shot', and indeed it was truly unreadable. And also the opposite, where the code was elegantly written and comments just enough to it was simple to understand, and also admire. I know which coder I would hire.
Hi Yog, what's one of the Outer Gods doing here on EETimes. The last I heard, you were described as: "congeries of iridescent globes, yet stupendous in its malign suggestiveness" -- and this was from someone who liked you.
I was going to say one can only hope that time has tempered your disposition ... howrever, reading your comment, I fear this is not so.
Personally, I think that anything that makes people think is a good idea -- and this type of thing certainly makes you think. Actually, when you do come to think about it, doing something badly when you know how to do it well is pretty difficult, like a brilliant singer trying to sound like someone who can't sing ... it's not as easy as it sounds (no pun intended).
Similarly, it's easy to write bad code if you don't have a clue (like me), but writing truly bad code when you are a good programmer takes some effort -- we're not talking about ordinary bad code here -- we're talking about code that would cause another good programmer to cringe at its awfulness.
A company I worked for had finally brought in-house the software that some consultants had written. We used to joke that all the developers there were regular contributors to the C Obfuscation Awards. Most of the code was unreadable. The first thing you were taught was "Names mean nothing", just because the subroutine was named "Print", does not mean it would ever get around to doing any. My favorite piece of code I had to unravel was named "DoSomething" with parameters A, B, C, D, E, F, G, H and no comments in the alphabet soup that followed. Subroutines would do 10 different things, but would be called because they were only interested in 2 of them, and hoped the other 8 did not have any adverse effects. A colleague and I traced one subroutine down 25 levels of calling such garbage and never hit bottom. By then we had absolutely no idea what the intent of the function was at all.
Sorry for the rant, but some people see this as being "clever" when they are coding.
Gee, Max, I thought the reference to beer and bacon would have you as the very first to sign up! I'm completely disqualified in any case, as I gave up trying to master C syntax back in the mid-'80s. I can read it, but no way can I write any C code!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.