Ask HN: What are your best tips for deciphering code in an inherited project? | Hacker News Reader

Ask HN: What are your best tips for deciphering code in an inherited project?

6 pointstomswartz075 comments

I've recently been tasked with restoring an old software toolkit to working order.

Unfortunately, the original project maintainer is no longer available, and the code is about as tangled as a plate of spaghetti. There are lots of outdated dependencies, and documentation is (of course) practically non-existant. We've all been there, right?

SO: What are your best suggestions for auditing/editing an inherited project, especially one that seems to fight you the whole way?

View on HN

I once inherited a big desktop app. It was a mess (everything was in one package, all methods and data were public, it didn't compile and there was no versioning history).

I started by breaking down the code into a few major sections and isolating them into their own modules. This helped me focus on one section of the code at a time without having to understand the whole thing. Then I made as much of the code as possible private. As long as the interfaces were clean, I could fix up the internals at my leisure - or hand them out for others to fix. Then I tried to get it to compile. Then whenever I ran into a runtime problem, I was cleanup that section of code while I fixed the bug.

tl;dr - Divide and conquer. Julius Caesar for the win!

Very cool.

Did you find it difficult to decipher the other programmer's 'style'? The project I'm working on, in particular, has a number of crazy quirks and hacks to get it to work.

I've worked on a number of inherited projects of varying quality. The biggest trick is to figure out what is working and what is broken, what's minor vs major. In that regard, you should try and get someone who uses or used to use the application to walk you through it. Then like taproot focus on the important parts or the small-hanging fruit.

Also if the project is small enough, it's often very informative to manually trace out the main code flows.

Also if you're having trouble understanding the programmer's style it's often useful to understand their background. Often the style or technique they use is because they have a background in a different language/library that uses it. EDITED: Personally I would avoid changing the style, because it's quite easy to make a typo or mistake that's hard to catch because you don't understand the application.

I find it very useful to have an environment/toolchain that allows for quick validation of assumptions. Just something where I can quickly drop some code to see if it does what I think it does. If I get more comfortable, I start to write tests. For some stuff it helps me to put the hight level concept on paper in a flowchart or diagram.

Run some code formatter over the source if you get angry about indentation or other stuff that works you up.

Don't underestimate the human behind the old code. It might look wild to you, but the other coder had probably something in mind. :)

EDIT: about the fighting: Make peace with the code. You can't time travel away the problems. For me, I need to constantly adjust my mental attitude towards unfamiliar code. Sometimes that even helps a bit.

One book that might give you some useful advice is "Working Effectively with Legacy Code" by Michael Feathers:

http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...

Reply on news.ycombinator.com