What are good techniques for keeping your place in code?

Question

I understand using bookmarks to remember a single point in your code. However, how does one keep track of the flow of the code they are investigating? Eg: multiple bookmarks and the order in which they were made.

Example:

1. Bug report: "Collisions aren't working on the corners of walls"

   1. Reproduction of the bug puts it down to certain polygons not colliding.
   2. The collision code was written by an unavailable dev. So investigation goes something like:

During the investigation, especially when reviewing non-code items such as Google, one may reasonably be expected to loose their place in the code (Have I already looked at this code path? or Which code path was I investigating? There are multiple that lead to this function, etc). The same goes for unavoidable interruptions (Boss: I need [Lengthy Pointless Report] NOW, etc)

It would be useful to have a resource of techniques or tools for providing a way to keep track of one's place in the code.

---

Edit: The above example is meant as a potential illustration, not as an actual problem that needs answering.

Another way to phrase this question is:

When learning a new system, how do you keep track of where you are up to in learning the code? It's not about understanding why the code does what it does (which is what comments should be for), but how it does it (which is only learned through reading the code, not comments).

Answer 1

The bubbles interface attempts to solve this problem by showing a bunch of bits of code at once. (You're stuck with your browser for Googling). It looks amazing but I haven't tried it. This version of the idea is a Visual Studio implementation for Visual Studio Ultimate.

Answer 2

Aside from all the great technologies mentioned, I've found that the old-fashioned A3 piece of paper is an excellent help in these issues. Write down your ideas and organize them mindmap-style.

Answer 3

Both my editor and debugger can jump to a function's definition and have a multilevel "back" button like a web browser to return where I was before. That's usually sufficient for me to keep track of a complex debugging flow. It also helps to have source control that lets you commit a lot. That gives me a commit message explaining why I'm trying something, as well as a quick way to back out the change if it doesn't work. Other than that, a simple whiteboard to list potential and explored leads fills any remaining gaps for me.

Answer 4

Multiple ways that I keep track:

• Write it down. Got a meeting in two minutes? Write down what you were doing and where. I always have pen and paper laying next to me to write things down as I code.
• Bookmarks. I have 10 numbered bookmarks I can set.
• Stacktrace. You can easily view the whole hierarchy of code you went through. My editor also allows me to copy the stack trace and save it. The next time I open my editor I can load the stacktrace for fast navigation.
• Editor navigation. Go to base member, go to inheritor, find usages, go to reference,...

Answer 5

I use the simple solution - never close anything until I am finished with the task. That means that usually one of the 50 or so open windows/tabs has something in it that will remind me what I was thinking when I get back to it.

Answer 6

Get a real developers tool / IDE, what ever takes you fancy. Vi, Emacs, Eclipse or whatever (The choice is as large as the arguements over which is best, but thats another problem), and learn to use it properly. dont, like too many do, use it like Notepad with syntax highlighing. Learn to use hotkeys, and not rely on the mouse for common actions (It's too slow). A big screen (1920x1200 minimum) is benficial.

My dev tool has named (Slower but useful names make them persistant) and unnamed (Quick to insert and delete) bookmarks, forward and back browsing and reference look up all in one, todo and developer (personal and group wide) notes attached to a particular line of source code. It does every language under the sun, without having to install yet another plugin.

I work on a code base consisting of a dozen or more 1 Million plus SLOC modules, using half a dozen languages. Obviously I don't work on all of them at a time, rather focus on small parts of one or two, but I can navigate with a few actions to any point in the code that is relivent to what I am doing.

Answer 7

With Visual Studio, in a debug session, you can use the 'Call Stack' window (you can enable it in Debug / Windows / Call Stack or with the shortcut Ctrl+Alt+c) to track of the flow of code.

Answer 8

I'm surprised no one has mentioned the many tools that can create call-graph plots. I've found doxygen to be a great help. You don't even have to commit to using doxygen throughout your program, you can just tag the functions you are interested in tracing.

Answer 9

I use org mode for emacs, which is an uber-outlining tool. With it, I can write an outline which mimics the call stack of the code and include direct links to the source code itself (via org-store-link). You can include explanatory text, links to web pages, etc. (e.g. when you google for magic numbers)

It's not perfect. For example the outline structure doesn't have any notion of going back up a level, so it's difficult to trace an execution path, as opposed to just a stack. But it's the next best thing to diagrams on paper that I've found.