top | item 1474718

A Tale of Two Code Bases ...

43 points| TheSandyWalsh | 15 years ago |sandywalsh.com | reply

17 comments

order
[+] angelbob|15 years ago|reply
I don't think it's a coincidence that the multiplatform codebase was cleaner. Very often, things will be written quickly and then you have to clean up a lot of the technical debt as part of porting it.

Your assumptions about the compiler/interpreter, file system and so on often break across platforms, so you have to revisit and repair that code as part of the porting process.

[+] ciupicri|15 years ago|reply
Quoting from "The Practice of Programming" by Brian W. Kernighan & Rob Pike:

Finally, and most important, a portable program is a better program. The effort invested to make a program portable also makes it better designed, better constructed, and more thoroughly tested. The techniques of portable programming are closely related to the techniques of good programming in general.

[+] ajuc|15 years ago|reply
And often someone else is porting the code - this is in fact code review, and this can only help codebase.
[+] tetha|15 years ago|reply
The major issue with creating clean code is that clean code requires a _lot_ of discpline, at least for me. Of course, if I am fresh and going, creating clean code is easy. Extract a method here, Invert that if, move that around and so on and so on and all becomes nice and cute. But if I am tired and annoyed by the code, I really have to force myself to extract that one convoluted condition, to remove that duplication and such.

Furthermore, I have observed that a lot of my co-students often struggle enough with getting stuff to work, and once they got it to work, uh, it works and no one really pulls himself together in order to get it into a nice, readable form, again, "Because it works, and I have other stuff to do.

So much to say, I had to debug a number of stuff in their code, and just by cleaning up stuff, I found bugs. sigh

[+] fendrak|15 years ago|reply
It's a shame that most of my Comp Sci peers don't seem to take much pride in actually building readable code. Building something that works is important, of course, but so is how it looks on the inside. Kind of analogous to building a house: sure, you can build something that keeps the rain off and the sun out in a relatively short time, but building it to stand the test of time is at least as important as keeping out the elements, if not more so.
[+] robryan|15 years ago|reply
Something that can happen is you keep to the standard of the current code when you start working on it, especially when something is contact freelance, no sense in undoing what is already there, just do the best you can to tack on what you need to.

One project I was working like this for a while, until it got to the point where it seemed I was going to be spending a lot of time on the code base. I was working around maybe 20% of the code that wasn't mine so I finally decided it would be worth the time to rewrite out the old bad practises.

[+] kiba|15 years ago|reply
It's a bit of a downer when he end the blog post with a cliffhanger.
[+] kenjackson|15 years ago|reply
"One feature I needed to remove, which was essentially a boolean check, touched over 40 files across four applications."

What does this mean? How does a feature span four applications?

[+] weaksauce|15 years ago|reply
Maybe it was a common utility function called from 4 applications that looked into 40 files to see if you had permissions to do something or to see if an operation was safe to do?

Seems excessive but....

[+] brown9-2|15 years ago|reply
How is bad code not the original developers' fault?