Live data from Hacker News

Ask HN: How do you familiarize yourself with a new codebase?

news.ycombinator.com

71–80 of 246 posts

Re: Ask HN: How do you familiarize yourself with a new codebase?

#71

Whatever your IDE/editor of choice is, I think these having these three functions are critical to learning a new codebase, or even developing for that matter: 1. Go to definition 2. Find all references 3. Navigate back This allows you to go down any code rabbit hole, figure stuff out, then get back to where you were. If you can't do those things it will take much longer to understand how things are interconnected.

Absolutely. In Emacs, I depend heavily on etags and the occasional rgrep to find my way around a fairly large project written mostly in C.

I haven't dealt with a JavaScript project large enough that I've bothered setting up tags, but I imagine something similar is available.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#72
post #52

Earlier quoted context omitted.

I'm not a younger programmer and I don't use a debugger. Tried it several times and found it counterproductive.

How is it counterproductive exactly? The setup of the debugger itself? Or trying to figure out how it works?

It depends on what you're working on.

If you're working on, say, a huge Java codebase, then a debugger is practically essential because you've got a lot of code to navigate, and you probably want to see what flavour of objects are being passed around and how their state is being updated.

On the other hand, if you're working on, ooh, a Nodejs codebase, you're probably looking at less code, with a debugger that's much slower, and probably more functional code that is operating on data directly. Using a debugger in that case is often slower than just using print statements.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#73
I use source navigator to understand the code base. I wish someone will keep improving it, especially the font etc under linux is not looking impressive, under Windows it's all I need. I'm unsure if other tools can provide as many functions for code base analysis.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#77

I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc. https://github.com/gilesbowkett/rewind it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects. the idea is, you need to know as much as possible right away. so you r…

thanks for making this and sharing!

Re: Ask HN: How do you familiarize yourself with a new codebase?

#78
post #52

Earlier quoted context omitted.

How is it counterproductive exactly? The setup of the debugger itself? Or trying to figure out how it works?

It's a complicated explanation I suppose, but I would say that among other things, I've seen my colleagues abusing debugging and since debugger is a "single threaded" and sequential approach if you will, they were losing the big picture. I try to understand the code and keep it in my memory so that I could predict the behaviour without the debugger. On a better day this would be a better explanation.

> I try to understand the code and keep it in my memory so that I could predict the behaviour without the debugger.

That's the theme I hear when prodding people who (sometimes loudly) say they don't use debuggers. They work on codebases that are either small, solo projects, or change very slowly. That way they can keep an accurate simulation of the entire program in their heads.

Meanwhile, I've always worked on codebases that were changing faster than I can keep up. The majority of my debugger time has been in code I've never seen before.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#80
I found call tracers to be the most efficient way to do this kind of thing. It could be as simple as a perl script inserting printfs on every call and every return, since not every compiler supports instrumentation.

Simply digging through code, tests or reading commit messages in an unfamiliar code base takes at least an order of magnitude more time.

EDIT: tried call graphs too, better than reading through code, but still require you to understand and filter out a lot of unnecessary information.

Post reply on HN