from Hacker News

Tips on reading and debugging other programmers' code

by el_programmador on 2/16/20, 8:04 AM with 25 comments

• by jeffrallen on 2/16/20, 3:17 PM

  Here's another point of view: don't read, nor attempt to understand, and certainly don't change what is not immediately relevant to the first bug you are assigned. Use the bug to guide your learning. Write a test for your bug... no testing framework? Add the first unit test, for your bug. Each task you do will guide you into the relevant part of the code. If you never venture into e.g. utils/common/math/sin.cpp that either means it is correct code you should not change, or that it is unused. In either case, it is irrelevant to your job.

  Unfortunately, the kind of environments that throw you into unknown code often change your project so fast that any attempt to understand the system more deeply will be soon lost as you change project again.

  This might be a nihilist view, but lots of coding jobs are essentially exercises in futility anyway, so might as well be efficient about it...

• by mattlondon on 2/16/20, 1:42 PM

  No mention of tests?

  If I need to debug someone's code, probably the first thing I ask is "are there test?" If you are lucky there might be some unit tests ... and they might even all pass too! :)

  Sometimes it is easier to debug a test then it is to debug the whole thing (due to isolating the code you are interested in). Even if it is easier to debug the running application, having a semi-decent suite of tests is your lifebelt for making sure you are not inadvertently changing behavior directly or indirectly.

  Other things I like to do:

  - ask if you are the best person to be doing this? Did it land in your inbox/task-list because people thought of your name first? Is there someone else better qualified/with-context who might be better to do anything before you even start thinking about it?

  - look at the change history of the code you are debugging - is it a "hot spot" that has had a lot of different hands fiddling around with it in the past (indicative of code that might have been troublesome and/or buggy in the past, with the risk of dirty hacks increasing as the number of changes per LOC increases...), or has it not been touched since check-in #1? If there have been lots of changes in that code go through the changes and look at the associated bug reports to make sure that any existing unit tests cover those scenarios (you may want to add them yourself if not, before you make any changes).

  - when reading someone else's code I actually find it better not to try to equip myself with all of the domain knowledge and docs. Often if the original developers are long-gone then the docs will likely be way out of date anyway, and sometimes it is easier to just be laser-focused on the parts you care about rather than try and get a handle on the whole system. I guess it depends on what you are doing though - i.e. simple bug-fixes or doing something more far-reaching).

• by dranka on 2/16/20, 2:49 PM

  If you are working on an old code base for a reasonable time I recommend to get to know the old developers. Check out the commit history, who wrote what, talk with them a bit if they are still around to get a feel for them. After a while you will probably see patterns, guy A usually wrote solid code, guy B a bit more sloppy. If you are investigating a bug in a specific area of the code use git blame and start investigating any additions by guy B first

• by JustSomeNobody on 2/16/20, 2:01 PM

  Skip 1 and 2. 3 becomes the new 1.

  2. Find an entry point. If it’s a CL find main and then where params are parsed. If it is a GUI or web app find a form or menu.

  3. Don’t debug, READ the code and trace with pencil and paper for notes. If you’re debugging you’re not reading.

  Wash, rinse and repeat a few times. Note all questions you may have.

  Now go find a domain expert to answer your questions.

• by chiefalchemist on 2/16/20, 2:35 PM

  I'd like to flip this around for a second. A note to management/leadership:

  1) Never assume the person(s) writing the code will be available in the future.

  2) Any given sprint should auto-add task/time for documenting and such. An hour or two now could save 5x, 10x or more later.

  3) The more critical the feature/functionality, the more important #2 becomes.

• by commandlinefan on 2/16/20, 2:37 PM

  Don’t forget, once you reach “senior” level (about 5 years experience), you’re expected to be able to do this in a day or two, regardless of codebase size or complexity.

• by RickJWagner on 2/16/20, 2:15 PM

  As a long-time maintenance programmer, I offer kudos to the author of this piece.

  As a group, we need to better understand how to read and debug code written by others.

• by medecau on 2/16/20, 6:21 PM

  The legacy code change algorithm:

  1. Identify change points.

  2. Find test points.

  3. Break dependencies.

  4. Write tests.

  5. Make changes and refactor.

  Working Effectively with Legacy Code, 2004, p. 18