The dirtiest code you will ever see

[nikki]

Today while reading the kernel sources for 'printk', I decided to write my own version of sprintf. About 20 minutes later I came out with this abomination:-
Click if you dare

[spacegaier]

The "good" old goto

[Klaim]

Urgh....



By the way, stackoverflow.com and thedailywtf.com are full of this kind of code that are in production softwares...

[xavier]

"Production software" doesn't necessarily mean "clean and elegant"; you should see some of the code in the games you play...

[Fulmens]

"Production software" doesn't necessarily mean "clean and elegant"; you should see some of the code in the games you play...

http://www.gamasutra.com/view/feature/4 ... tricks.php

Well...after i started to really work, I never saw computing sciences the same way

[Klaim]

I and my colleagues have done some too, sure

I remember that time when we were in the midle of the night trying to fix a bug that would add another bug in another level if you fix it on the first level and vice-versa. The boss was an elder programmer and came to my computer to see how he could help. Then he said : "this feature have different behavior in those two levels right?" - me:" yes" -"ok then make copy of this behaviour code targeted at the less commmon level and fix the bugs separately for each level".

It was the pork-est suggestion ever. But it did fix the problem

I remember other tricks like the ones in the article too.

[nikki]

Actually, I found code from popular open source projects to be pretty neat (except a few GNU things, like GlibC ).

[reptor]

A few years back I was a little shocked when a very experienced C programmer (retired, in fact) gave me his source code for a small program. It was a file conversion program.

The goto was in there in many places. But the code was hard to read in general, it was not just the goto, but all of it that was a problem. It was pretty much a mess. There were certainly no formatting rules in use for the source code when he wrote it - or perhaps he had a rule that formatting shall not matter! Certainly not good for the faint-hearted.

Hey, but the program worked... isn't that the whole purpose!?

I have to say I re-wrote the program in C++ and saw no noticeable performance decrease. If there was an actual decrease in the performance then it was very insignifant because it didn't really show up in my tests. Maybe with very big data there would have been some noticeable difference - or perhaps my code just was more effective (I find this hard to believe knowing I am not a pro in this business and knowing C should be the faster of the two languages).

[Klaim]

Often, it's the compiler that writes the dirty code


nikki> Yes and in fact I tend to write all very very clean in my home projects.... and as they are in constant refactoring it takes a lot longer to finish something...

Now I'm trying to learn how to get dirty sometimes. I learnt that if you isolate enough dirty code, it's easier to refactor, then you can focus on releasing something.

[mkultra333]

I only code dirty. Way dirtier than that sprintf function... That looked pretty clean to me. (Edit: Ok, I pretty much never use Goto, although the poor statement is so maligned I feel a certain compassion for it.)

I'm not a trained programmer, and I often find the "clever" fanatically OO projects vastly more difficult to understand than the more C like ones. Maybe because I'm always coming in from the outside, looking at open source code that usually has no documentation. Things like the source to Quake 3 Arena, Q3Map2 and various versions of Radiant. They usually lack anything in the way of code documentation and are fairly sparsely commented.

The worst was GtkRadiant. Intensely OO and totally incomprehensible. At least when I start trying to work out how a C-like program works I can plant message box and prints about the code to trace execution. That works with Quake 3. With GtkRadiant I just found program execution vanishing into the aether beyond a certain point. Now I'm using DarkRadiant which is a sort of refactored, cleaned version of GtkRadiant. It's still largly incomprehensible to me, but I have managed to get it doing what I want with more ease than GtkRadiant.

I think OO is oversold... too much is a bad thing, and I'm not really convinced that it's the only way to go on small or medium sized projects. I can see how it has its place when you have to keep a hundred programmers in line on a hundred million dollar project though. And I admit I should use it a little more myself.

[nikki]

Well, obviously 'OO just because OO' will be bad. If it's for the purpose of code reuse, abstraction or such, then it isn't bad. For example, having an abstract 'GameObject' class that's the parent of all logical objects in my game has helped a lot.

[_tommo_]

http://www.gamasutra.com/view/feature/4 ... tricks.php

Well...after i started to really work, I never saw computing sciences the same way

Good link

Anyway these times i tend to think that "dirty code" can even need strong programming skills! In fact, often i find myself speculating about an over-engineered solution to a simple problem... where a collection of specific solutions would be more solid and fast to develop.

One perfect example would be Lua support in my game: in the end the whole system was so much big and complicated, that changes were in fact HARDEST:
you had to change different lua files; the wrapper, or even the C++ code.
In the end creating an header-only class for each single item type, along with a Factory Pattern, was by many times the cleanest solution
This way i know exactly where and when i encounter one-time-use code... making it safer and more powerful that useless generic scripts.

In fact i thought that "YAGNI" was a thing for superficial developers... i didn't know that sometimes it is easier and more bug-proof to add "hacks" on "hacks" rather than putting everything in from the start and try to make code that does "anything"

[nikki]

Some more C fun! This time, it's tries.

[xavier]

In fact i thought that "YAGNI" was a thing for superficial developers... i didn't know that sometimes it is easier and more bug-proof to add "hacks" on "hacks" rather than putting everything in from the start and try to make code that does "anything"

I live and breathe YAGNI -- it's saved me so much time and headache and "analysis paralysis". Assumptions made at the beginning of a "framework" development rarely end up being how practice turns out to be...and then you get to go back and re-architect the entire app (or slap heinous hacks in to work around the now-artificial framework constraints). So I'm 100% with you on this one.

[Klaim]

Same here. Yesterday at night I refactored (totally rewritten in fact) an old event system in witch at the time (some years ago) I added some event cancelling functions, assuming it would be useful to cancel an event or events of the same message... I removed all that as it was never used and I got totally YAGNI style since last time I wrote this old code. That was a big relief, making the internal code really simple and explicit.

YAGNI, DRY, SoC are like Epice in my coffee

[syedhs]

IMO, YAGNI design approach can only truly be appreciated by people of experience - well for people like me Without any single dispute, it has been proven that designing software which fulfil today requirement is simply that simple & satisfying for both you - the developers and of course the clients. Designing for future is just BS, and for that development iteration is probably what it is for.

[Klaim]

IMO, YAGNI design approach can only truly be appreciated by people of experience

So true : this is not natural for beginners and it shouldn't be told until they hit problems relativee to it. That way, they understand the need. (but that takes time...)

[nikki]

Ok, now I made a little stack based scripting language after being inspired to do so reading the CPython source code. You can see it here. In case it isn't clear, $<name> basically creates a new variable with name <name>, popping a value off the stack and assigning it to it. There's no way to mutate (modify) variables yet. It's easy though, just that I have to sleep now.

There's a basic arithmetic function ('add') and output ('print'). It's easy to add new functions (check out ns_print and ns_add for the C versions of these, and ns_funcmap to see the script name -> function mapping). You can pass functions around, set a block of code to a variable, pass a block around etc. Kinda fun.