I've been working in a new codebase recently, and I've been struggling to navigate code. I don't think this code is organized particularly poorly, but I still find myself jumping around and having quite a few files/tabs open trying to follow the thread. In this case some of this code is object oriented and so there's lots of jumping between class and base classes (often multiple base classes deep...) to see where anything happens. I've used VIM marks in the past, I'm trying a bookmarking extension for VS Code, and sometimes I open multiple files in splits to keep things "in context", but I still feel like these are all less than ideal and it's very easy if I step away from my computer for a few minutes for it all to leak out of my brain and then I spend the next 30 minutes trying to get it all back before I can work on the problem.<p>Looking for any tips you all might have for making this easier.
I use VSCode and mostly navigate via:<p>F12: Go to definition<p>Shift+F12: Go to usages<p>Ctrl+-: Go back<p>Ctrl+Shift+-: Go forward<p>Once you get used to it, it's as easy as browsing the web.<p>Since I started using VSCode I did not have to work with codebases that were complex enough to make these features valuable but some VSCode language extensions support tree views of call hierarchies and type hierarchies. Here's the documentation for the Java extension.<p><a href="https://code.visualstudio.com/docs/java/java-editing#_call-hierarchy" rel="nofollow">https://code.visualstudio.com/docs/java/java-editing#_call-h...</a><p><a href="https://code.visualstudio.com/docs/java/java-editing#_type-hierarchy" rel="nofollow">https://code.visualstudio.com/docs/java/java-editing#_type-h...</a><p>You can set keybindings for them too.
Depends on what I am trying to achieve.<p>Most code (especially legacy code) has more branches than typically matter: the majority of branches is error handling or special cases and can be ignored when investigating core functionality. Executing the happy path test case for the functionality I want to extend or bug fix and then stepping through the code with a debugger or manually is my usual mode.<p>I use IntelliJ myself. Being able to step through with a debugger can be a huge help to show actual implementations used in polymorphic code but few test suites are sophisticated enough to guarantee the possibility. Sometimes I will refactor code simultaneously in order to make it more comprehensible; that obviously requires some tests and experience but if you have the tests take the time to gain the experience and otherwise write the tests! Especially BDD style tests, the kind that survive refactoring.
IntellIJ IDEA Ctrl-click, Ctrl-Shift-F, Ctrl-U, etc, Sourcegraph when I don't know which repo or do a company-wide code search or examples.
Having a lot of tabs open for a single flow of data makes my brain forget about the start of the flow, so I put named bookmarks as I go when doing this. When debugging, the same kind of flow debugging, I use conditionnal non-suspend logging breakpoints that print out relevant stuff from variables in scope.
One of the most important parts in this is closing all tabs from time to time, and putting 2 open files side-by-side, 1440p monitor helps, or splitting part of the IDE instance into a separate window on another monitor.
If my code's jumping around a lot I throw some keywords in the comments with unique numbers like verificationworkflow13 so with ctrl-f I can easily jump through the entire chain, or I can go straight to a specific step. Same concept as bookmarking but more flexible and it solves my problem of having a disorganized mess of too many bookmarks. It also helps for keeping things organized in my head ("this is part of the verification workflow between parts 12 and 14").
NeoVim + language servers + global search with rg + a bunch of keyboard shortcuts:<p>- <spc>gd = go to definition<p>- <spc>gr = open a hovering window filled with references to symbol<p>This is enough to get through every codebase I've yet encountered (Go, Typescript, Python, Java, C++). I also like to use <C-I> and <C-O> in vim which allows you to jump between the most recently viewed locations.<p>For keeping context, I just write everything down! Either in a scratch file or on a digital notetaking app on my iPad.
I had a similar requirements some time ago - I thought one nice way would be to write a Markdown file to be read inside VSCode with links to the files' lines/positions, but couldn't find an extension that worked like this. Settled for "Bookmarks" at the time. The "Code Tour" extension can also be used for this.
I have a weird workflow I think. I use ripgrep in the terminal to find relevant files and then run `subl $FILE` to open the file in Sublime Text in the foreground. Sublime knows to open the file in the window where the directory is already opened as a project.<p>I should probably use an IDE but I just don't like them. Sublime is insanely fast and lightweight. I don't want to wait for anything to happen and I find my current workflow allows me to navigate codebases quickly anyway.
I would just remember some keywords in either code or the file name and do global search, I barely use splits though bc I think it’s kinda distracting.
I’ll follow a lot of the vscode tips in this thread plus a helping of running Doxygen on the project. Even without the specific Doxygen markup in the headers, running Doxygen can help with the call graphs and object hierarchies with a browsable interface.
This is basically how I do it in Vim: <a href="https://vimways.org/2018/death-by-a-thousand-files/" rel="nofollow">https://vimways.org/2018/death-by-a-thousand-files/</a>
If the computation jumps around between multiple files/classes, I document that on paper. Often when working on a new codebase, I end up surrounded by many pieces of paper documenting flows and type hierarchies.
grep -ri and then vim the interesting files. that's mostly web dev and scripting languages.<p>In the old days when I did more Java dev, I used Eclipse to view where things are defined and find usages.
step through it in a debugger;<p>run strace or ltrace on it;<p>grep: works better with editor assistance, such as emacs M-x grep;<p>write documentation for it;<p>factor out parts of it;
grep or vscode search / definitions.<p>Take some rough notes on a google doc / gedit so that I don't forget paths that I've explored previously