

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

I&#x27;ve recently been tasked with restoring an old software toolkit to working order.<p>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&#x27;ve all been there, right?<p>SO: What are your best suggestions for auditing&#x2F;editing an inherited project, especially one that seems to fight you the whole way?
======
taprun
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!

~~~
tomswartz07
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.

------
twunde
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.

------
seven
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.

------
greenyoda
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...](http://www.amazon.com/Working-Effectively-Legacy-Michael-
Feathers/dp/0131177052)

