nice little article here

Hah. In some cases you have to rewrite. Ironically, like the Netscape 4. From what I gather it was SO horrible, that they couldn't continue with it. I know for a fact that the later 4.x versions were horribly buggy, and lacking in features.

I don't agree with his blanket statement. (Yes, I read the article.) I'm sure it's true under some circumstances, but in my experience if you come across code written by incompetent fools, you are better off burning it and starting over.

For instance, at a previous job in a previous life, a co-worker had been working on a web project for three months. The project manager came to me and asked me to "take over" since the deadline was rapidly approaching. After taking one look at the code, my eyes started to bleed. That weekend, I re-wrote the entire thing from scratch. Came in on that Monday, and handed it him. I couldn't care less that it meant they just wasted three months of salary on her.

Now I know that Joel is talking about re-writing code that already "works," so my example may not be at all what he is talking about. But he considered Netscape 4 as something that "worked," which is a very bad example. Netscape 4 was very screwed up; IE 4 was blowing it away. He obviously never had to look at it from a developer's perspective.

I don't think he looked at it from a USER's perspective.

To be clear, I mean a 3rd party web-developer as opposed to a Netscape developer.

Old.

[EDIT]
Although I agree with the article.

My personal experience:
One thing to avoid the "start from scratch all over again" is to re-write and re-design your project from time to time, to make it more readable.
In my current project I re-designed a few classes that already worked perfect! but I was not happy with them, because they looked a bit messy, I spent time in the re-design, and I am sure that players will never notice the difference, but as a developer I feel better, because now I have a more legible code.
I allways try to achieve readability because, as the articles said:

Ya I'm not sure about that point. I doubt source code from Netscape 4.0 would stand a chance against all the new standards for CSS and javascript. Maybe some code could be preserved, but the majority could not.

In the feedback link they talk about redoing the FTP code. Heh, now that makes no sense at all.

That Joel guy would not get a job at the company I work for.

Let me reword that.

We have some golden library design rules at work. They work amazingly well. We can understand our code six months later (shock!), and we can all modify each other's code with confidence and success. It's great!

[EDIT]
Actually, he changes his mind halfway through. He starts off by saying that old code isn't messy, but then he changes his mind and concedes that actually it is messy and does need careful refactoring (which is often true). He might get a job then.

Ah, ok. But to be clear, I mean from a plain old user's perspective.

Slightly off-topic: Among artists it is common practice to redo some of their old works to learn and to see how they have improved over time. Maybe that's the same reason to rewrite old code, aside from the functional reason of course (code that doesn't work just needs to be fixed/rewritten, whereas a crappy piece of art can still stay as it is, as it doesn't have a well defined function like code has).

That is called extreme programming: you program thinking in today and dismissing tomorrow. So, instead of thinking "I may need a new argument for this function" you say "I only need these arguments for this function". It is good for evolutionary design, the one where you need to create a prototype, show it to clients, get suggestions, and then update the prototype with the suggestions. We used it at work, but found it to be costly (especially when you have a limited number of programmers).

The truth is, when you are dealing with a 9 year old product (like the one I work with), you usually find several old paradigms that are outdated, and need to write a lot of code again. Personally, in four years I threw many components away, trimmed others, and fully recreated the contraindication module, the drug database, the graphical interface, allergies and, after three weeks, the settings (so that you can query for settings or show the graphical interface to change settings anywhere in the program, for maximum customization). None of these changes would have been possible with the old code (to give some examples, in Visual Basic nobody used implementations until three years ago, there were copies of the same function everywhere, and there were even rem comments... and in the C++ part, a component had created the full COM interface manually, hardcoding the GUIDs, another had an abusive hierarchy of 15 levels, none of which has siblings--think in a hierarchy that looks like a vertical line without branches--, and another was a horizontal one, where leaves did not inherit from each other but instead always repeated code from other classes).

Gamasutra has a feature about it, Embracing Fun: Why Extreme Programming is Great for Game Development.

"Don't rewrite your old code" is a great title, actually. It doesn't say "Don't rewrite somebody else's old code".

Sometimes the title is ten times better than the article itself

Joel makes a good point, from a business perspective. If you've got a product that "works", reverting back to something that doesn't makes no sense at all.

That doesn't mean that a certain subset of the code can't be rewritten. In fact, it's probably a good idea to pull out a chunk of code, do some spring cleaning (and by which, I mean rewrite it), and refit it back into the codebase.

When you're dealing with 0.25+ MLOC codebases, rewriting and redebugging them in their entirety is often not a viable option.

How well do they work on a long-term basis? Over a 3-5 year basis, yes it's possible to come up with rules and techniques to keep things manageable. When you have a 8+ year old codebase, a lot of things tend to change over time to make the existing code inadequate.

The metric I use is a shelf life of good quality code is 5 years. Call it Bob's Law if you will Basically, you will need to rewrite your code every 5 years. Plan for it.

Code does rot. Not because the code itself functions less over time, or because defects magically insert themselves. It's simply because the requirements change, and keep changing even after the product has shipped. These requirements may not even be under your control, or the control of your company. For example, the OS changes, CPUs get faster, you now need a port to some other platform, etc. The existing code, being static by definition, does not keep up with these changes.

When you do need to make changes to the codebase, you also need to look at things from a business perspective. What's the !/$ of the change? Do the small incremental changes you need to make warrant a complete rewrite to make them a better fit for the architecture?

Of course, you also need to weigh in some metric based on the "mass" of the code. Is the code in such as shape that it will collapse onto itself and turn into a blackhole, sucking all development time into nothingness?

I don't know what the state of Netscape 4 was at the time. In retrospect, it was definitely a bad idea to rewrite it from scratch. But the neat thing about hindsight is that it's always 20/20. It cost Netscape 2 years of time where they had no new product on the market. No new product == no income. Loss of market share and mindshare. That's a really bad position to be in, business wise.

I am shared.

Don't we always say that reinventing the wheel is bad ?

Of course, if the code is a total mess, then rewrite ! But if it is good code, nicely organized and structured, where is the need huh ?

Netscape didn't make any proffit from The browser at that point anyway, Microsoft forced them to give it away. All it cost was the manpower to write it. And they did get some help from the community (albeit not that much).

Netscape made a majority of their income from their server business even when they were selling the browser. And it shows in how they let the browser rot.

That said, excellent view Bob. I'm adding this to my threadbook.

For the point I was making, they should work for ever. All our golden rules are ultimately designed to keep the code clear and easy to work with. Of course we have to rewrite or adjust code if requirements change (or if Sun break Java) - but we never have to rewrite code just because we can't understand it. Joel's point was that people have trouble reading other people's code or their own old code, and that just isn't true for us.

Now, Sun's standard library code, on the other hand ... Jesus Christ. No wonder they break Java so often.

Something I have learned in five years as professional programmer: you never rewrite code to fix bugs, you rewrite it to add new features.

I do exactly the opposite! But then again, the code I work with has a low average quality.

If the wheel doesn't fit the cart, you need a new wheel.

Then invent it!

Or a new cart.

Or a new axel to piece together the two incompatible things

..or an elephant to drag the cart along without its wheels. ..or an assassin to wipe out the client waiting for the cart. I'm sure these can be massaged into metaphors for certain industry practices

When the cost of modifying the cart to fit the wheel is greater than the cost of getting a new wheel, you should get a new wheel.

Why use that old cart? When you can get... the Ultra-Cart 5000! Its fast, its sleek, its wheels are always compatible with the cart and the axle*. And what's more, it requires no elephant** and is assassin resistant***. Only two hundred seventy-six EASY payments of $99.99****! Supplies are limited, buy now.

-----------------------------------------------------------------------------------

*Wheel-axle-cart compatability not guaranteed.
**Elephant may be required in polar regions.
***Assassin defenses are limited to the delux edition.
****Must be paid in cash and all the payments are required within two days of purchase.

I have a double moral.

I like to rewrite from scratch my own code, because I do it as a hobby, and is fun, and educational, and I usually get better results.

I don't like, and I don't think that is good (usually, there are cases were is good) to rewrite business code from working systems that are used to generate revenue. In those systems, I think that the KISS approach, and the "don't fix it until it is broken" really apply.

That's what branching is for.
When something isn't broken but you would gain a lot by impoving it, you create a branch so you can work on it until it works without messing up the trunk.

my old code needs rewriting. And this is only a few weeks old

it works, though.

     rect(buffer, 0, 410, 640, 480, makecol(255, 255, 255));
     rect(buffer, 1, 411, 639, 479, makecol(192, 192, 192));
     rect(buffer, 2, 412, 638, 478, makecol(128, 128, 128));
     rect(buffer, 3, 413, 637, 477, makecol(96, 96, 96));
     rect(buffer, 4, 414, 636, 476, makecol(64, 64, 64));
     rect(buffer, 5, 415, 635, 475, makecol(32, 32, 32));
     rectfill(buffer, 6, 416, 634, 474, makecol(0, 0, 0));

Ever heard of for loops?
Then there's the clear_keybuf() (In a drawing function. When you're not even using readkey().), the non-returning main, the complete lack of return value checking... Gah!

And for the love of the Antichrist, stop using rest() timing...

I would look into using a DATAFILE to store your images. it would make it easier to keep track of later.

I told you it needs re-writing.;D

At the present I'm very attempted to rewrite one application. It has a rather large allegro dialog struct and the indices are somehow wrong. Months ago I added something to the dialog and never got it ready. Now I need to make it ready and I have a hard time debugging it. It compiles and runs, but doesn't do the thing it should. And it is because indices are wrong. It's all about image manipulation and I have these radio buttons for whether creating a new file or overwriting the old. And some buttons for jpg quality. So when I wan't to make resized copies of all images in a folder, it overwrites all images with b/w, unresized, really screwed up versions of the images.

The main problem is only in my coding style. I haven't figured out how to write maintainable code what comes to allegro dialogs. It would be nice to have a way of using macros or something for the indices, so if you add one item in the middle of the dialog struct, you wouldn't have to change the indices all over the code. I bet masking or any other gui lib handles this better.

That code does not need rewriting!!

I read it quickly and understood it pretty easily. I don't know what all the functions you haven't included do, but there's nothing in there that looks particularly bad. Fixing the location of the clear_keybuf call is a question of moving the line from one place to another. The 'rest' timing thing is a bit harder to fix, but only because Allegro has such a horrible timing API (it doesn't even have a 'get current time' function) - and it's still only a question of writing more code, not throwing the old code away. (The problem is that the code running in between calls to 'rest' also takes time, thereby slowing the game down on slower computers, since gnolam didn't have the manners to tell you.) You could change it to use datafiles, but you don't have to; I don't see how it makes it easier, it just keeps everything nicely in one file and allows you to compress it. And there is no need to write that series of rects as a loop; the existing code is short and it's clear, and if you use a loop, you'll have to generate the series of colour values somehow - perhaps using an array. It'll also be slower. There's just no point.

Seriously, don't rewrite that code. There's nothing fundamentally wrong with it. There may be tweaks you can make, or you may have to rethink parts of it as you add to the project (but only if they don't work or start getting messy), but that's it.

Sounds to me as if that's your only reason not to like the project. I also remember having a bit of trouble with that myself. I think I built the array up at run time, using a macro that fills all the fields in and then increments a counter - and then, when I needed to know an index, I just added a line that copied the value of the counter variable. That would be a bit of a 'rewrite', but you could still use a fair amount of creative copying, pasting, searching and replacing to get it done.

I use Julien Cugniere's dlg editor, which is actually very good. As good as the whole damn allegro gui system deserves. Worth its price, like Gimp. The editor does some nice things, it aligns all dialog entries nicely, you can muve each entry up or down in the struct (changing draw order), it draws even rects for custom procs. But when changing the order, you have to figure out the new indices and change your code manually. And that's the pain.

Did I mention that I have clear_keybuf() in almost every function? For some reason I couldn't get the dialouge to work any other way (the game would immediately read a second keypress and close the dialouge before the player could read it.)

Are you using key[] to check for your keys? All you're doing there is reading from an array, without changing its contents. The key[] array is the status of each key: whether it's held or not.

If you are using Allegro's GUI, then that uses readkey() to detect its key-presses. You should consider whether readkey() is better for your purpose too. You can use readkey() to get a key from the buffer - and have it removed from the buffer so nothing else can read it again - and if you don't want the function to block, you can call keypressed() first to check whether there is a key in there. See the docs for more information.

If you indeed find that key[] is more appropriate, then why don't you call clear_keybuf() in just the right place, just before you show the dialogue?

Possumdude0: It is because your code is a mess.

Ta gueule.

clear_keybuf doesn't touch the key array. It just clears the keypressed/readkey queue. The only (valid) way to modify the key array is to press or release a key on your keyboard.

Tu peux la fermer?

Don't re-write old code. Write it correctly in the first place. If it turns out not to be flexible or adaptable enough then you'll have to redesign it from scratch.

edit: damn my post button skills are too fast!
I forgot to add that if you have crappy code, or you try to extend it too many times you could end up with vista!

That is what is implied by "rewriting old code". You would NEVER rewrite an app the same way twice. Unless it was a perfectly coded piece of ART that you somehow lost the source to.

I use defines for this, although enums would be better (I have been doing this since before I knew C thoroughly) This list of defines (or enum) needs to kept manually in sync with changes to the dialog, but it saves shlepping through the rest of the code. Hopefully, the dialog editor in DevAlleg will automatically maintain this list by associating the 'ID' with the relevant index. This has stalled because I want to parse the entire file for everything, because dlg's way of doing it does not preserve comments etc., and does not have automatic run-time initialisation code refactoring.

This is what I do in my ogg_encoder tool for apeg (which relies quite a bit on object "positions").

That way if I add or remove a widget, I just need to modify the one macro below it, and all the macros in the dialog remain in sync.

Hey Bruce, do you have a problem ? Even if is your French is good, it is not good enough to crush me at French bashing, baby .

Now, for your French practicing, a little bit of informations:
Reste cool, je n'ai agressé personne. Quand bien même PossumDude0 se sentirais blessé, se serait à lui de le montrer, et non à toi. "Ta Gueule" est une expression qui est loin d'être poli. A la limite tu aurais posté un "Ta Gull" et cela aurait pu passer pour une taquinerie. Pour ta culture personnelle, la définition suivante convient parfaitement au mot poli: Dont le comportement, les manières, le langage sont conformes aux règles de la bienséance, au respect des convenances. Ce qui est loin d'être le cas de ta remarque.

That is the difference between the French and Canadian speak ;-) You Canadian are more courteous than us the French ;-) ( and even more courteous than people learning French. )

Mark Oates: sorry. I did not want to derail the thread.

PossumDude0: Were you really shocked ? If so I tell you now there was no reason as it was joking. If not, heh, have a nice day.

Now, back on the thread rail:
As Johan, I am also using dlg from Julien Cugnieres, it fits my needs perfectly.
You should really give it a try.

EDIT:
A simple copy-paste in a file with Matt dialog give me this:
{"name":"591667","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/b\/2bc4bad99c0f4f66dfa4785659d86082.jpg","w":646,"h":505,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/b\/2bc4bad99c0f4f66dfa4785659d86082"}
_

Whoa. All that reply to a post with two words in it!

Your post just didn't seem funny. It seemed little more than an insult. If I can take it wrongly, then a lot of people could. It was worth my posting that, because now it's painfully clear you meant it as a joke

(I wondered if you were going to flaunt your native French at me )

In canada we have a saying for "english people" who just don't get it...

My my my, Bruce. We misunderstood each other !

Lets say it is OK now

While I wrote my answer I was remembering the long talk we had on irc some times ago, and your post made me a little bit angry ( as I was really joking PossumDude0 this time ).

Bwahbwahbwahbwah, everything is under control now :-)

I just noticed something in my code. It looks like KEY_PLUS_PAD will decrease the speed, and KEY_MINUS_PAD will increase it!?

It is quite logical in my oppinion, you are changing friction. When you lessen the friction your whatever_it_is will move faster.

Oh yeah, I was decreasing the delay, which increased the speed... brain fart!

Halflife sourcecode:
float m_frictionFraction; // Sorry, couldn't resist this name
dlls\triggers.cpp (line 56)

PossumDude - do you not know how to clean up after yourself? Your program seems to leak a nice chunk of memory, depending on the size of those bitmaps.

1) I don't really understand what leaking memory is, but I can tell it's important and I need to learn it, it's Google-time!

2) That program, as I have already stated, need rewriting. It is also unfinished, because they cut off my electricity when I had barely gotten things displaying properly. But I'm getting my electicity back on next week! I hope...

Memory leaks when memory is reserved by a program and never released back to the operating system. When the program closes the operating system doesn't know the memory is free so it will not give it to another program. That memory is essentially unusable until the computer restarts (or possible the operating system determines that it's not in use, but I don't think this happens).

**See following posts**

In other words, when you create a variable in your program, your program has to request memory from the operating system, which controls the entire computer. If it has the memory available it will probably grant it to you. If not, depending on the system, it will probably somehow message your program to indicate that there isn't enough memory. If your program doesn't handle this (probably an exception) your program will otherwise crash.

Once the operating system grants your program access to memory no other program should be allowed to use it (that is dependent on the operating system, but I assume XP or Vista do this; and I'm very certain that *nix systems do). That will ensure that another program doesn't overwrite a variable on you and mess up your program.

When your program is finished with memory, it should release it so the operating system can give it to some other program.

A simple example:

Sorry if I went over too much, but I figured there's no point explaining just the new and delete stuff if you, or somebody else stumbling across this thread, doesn't understand a bit about pointers and memory addresses.

Any decently modern operating system will free the memory once a program closes.

The main problem comes when your program runs for more than a few seconds, if you never free memory that you allocate, it'll keep building up and eventually run out of memory, cause the OS to start swaping stuff to disk, and then things get really slow.

If you new/malloc/create_bitmap/load_bitmap you must free the memory (delete/free/destroy_bitmap/destroy_bitmap) when you are done with it.

Ah yes. So I guess when your program exits the operating system should be able to clean up any unreleased memory (makes logical sense). However, during the execution of your program you can hog a ton of memory that's not even in use anymore if you don't release it properly.

I think I just said that. Did you read the entire post?

Shit no. Do you think I have time to read a fucking novel like that! Tone it down a bit.

Obviously, you're gonna freak out on that so allow me to apologize. That last post was really my "I'm embarassed as I should have known that and yes, I think he's right" post.

I thought that the operating system usually throws large idle programs out to swap in an attempt to free memory ahead of time and also so it can load things into memory that it predicts will be needed soon. I'm not really an expert on operating systems though. Anybody know of a good OS writing tutorial? {smiley}

Uh, You seem to be upset

I freaked out? It was a simple question.

Sorta. It mainly swaps when asked. I something needs ram, and theres no physical ram left, the OS will swap some pages to free enough (and maybe more) for the request.

Linux will end up swaping some way underused programs if they almost are never used, and the file/disk cache is well used. (it'll swap stuff to make room for disk cache)

edit: Also, Vista has added proper file/disk caching as well, so I'll bet it will do the same. Of course it also added extra app caching features with flash drives and whatnot.

No, that was said sarcastically. I would have made it more obvious, but I assume it's still EFW. When does that end exactly?

I didn't want you to freak out because I referred to your post as a novel. I'm sure regular users have realized by now that I often have long replies.

And it sounded like you thought I was trying to take credit for your answer. I just wanted to clear it up... I can see now that it's gonna take a while.

Not at all. I just have a small beef with people not reading posts.

Indeed; hence, (warning; evil suggestion) you can often greatly optimize shut-down times of programs using a lot of dynamically allocated memory - especially ones with a ton of destructors or other cleanup functions to be called - by simply doing a quick-and-dirty exit, focusing proper memory management on the parts of the program active during its lifetime.

My concern is which is faster and more reliable: explicitly cleaning things up or the operating system cleaning up the mess you leave behind?

The os can probably just defer the freeing of stuff. If the program isn't meant to do anything fancy, and doesn't run long, you don't NEED to free any of the mem yourself.

Unfortunately not all resources are memory, theres also threads, Window Handles, GDI resources, X11 Resources, and occasionally, if you don't free those sorts of things, they may not be freed correctly. Win 9x has always had a NASTY problem with not freeing ANY GDI, KERNEL32, or USER32 handles by itself when an app crashes or even just forgets to free stuff. I've you've ever seen the GUI turn into a copy of Win3.1, you just ran out of GDI handles.

Its a lot harder to do the same in 2k and XP though, since its based on a much better kernel.

Personally, not freeing stuff feels dirty, and wrong. I prefer to do things the right way when I can.

I'm the same way. For me it's a compulsion. That's also why I edit forum posts so often. If I don't do things "perfectly" I'm compelled to fix them.

(I've been drinking Canadian beer... I don't know if I'm making spelling/grammar errors right now... :'()

Yeah, I usually try, but some of the time I don't even notice the errors, and anal people like to throw witty remarks around about my errors (so sue me if I have a mild case of dyslexia and really bad recall).

I actually have hit that before (tons of leaked GDI handles in XP). XP tops out around 32,000 handles, and when they get leaked by various crappy programs over the course of 8-10 weeks (my average reboot cycle), you can end up having those issues. However, it's normally programs that stay running. Also, if you log out/back on on XP, it seems to clean out a bunch of those leaked GDI handles.

[edit]
X-Chat falls under the crappy programs category. It only has 129 GDI handles, however, somehow it has managed ot eat up 5,017 handles and 1,152 threads.

The OS will catch it all, so the reliability is not affected when you perform a given part of the memory freeing manually. And doing it manually often requires many relatively costly freeing calls - and often executing much other code, particularly in heavily OO-structured programs where multiple destructurs may be called for each of many objects. Slightly slower at best, much slower at worst.

And there you can have reason to do things "properly". When it is guaranteed that avoiding running code won't do any harm, though, it makes no more sense to put it in than adding a sleep call.

That goes for me as well, only what I see as being "perfect" is different; I go to great (sometimes semi-obsessive) lengths to avoid redundancy and overhead.

Yeah, I would say it is semi-obsessive of me as well. Refer to the Off-Topic thread started a few weeks ago titled Post a weird fact about you...........

Or for a direct link to those relevant posts:

• Intro

• F.E.A.R.

• Unpure

• Spelling and Grammar

• Obsessive-Compulsion

What I see as being perfect is probably relative to the situation.

You are OCD, yet you still write unclean PHP code? That doesn't sound right to me.

I've never been diagnosed. As far as unclean PHP code, that depends on your definition of unclean. To me it was cleaner. Dynamically-typed langauges are considered unclean to me, so I only use them when I have to.