• by blt on 7/31/2022, 3:57:25 AM

    Many features in IDEs like "jump to definition" and "find references" are already designed for reading code. Reading code is a huge part of software development, so generic software development tools should already be good for reading code.

  • by tgflynn on 7/30/2022, 8:43:57 PM

    I don't see the need. If you're worried about making accidental changes there are many ways to prevent that, depending on editor/IDE and OS. For me almost all the code I look at is checked into some git repo so accidental changes are a non-issue.

  • by fxtentacle on 7/30/2022, 10:21:39 PM

    The JetBrains IDEs are fantastic for exploring unknown code.

  • by pmontra on 7/30/2022, 8:23:36 PM

    Most of the times I use less in the terminal. Or vi, it's not easy to accidentally make a change and save it. Or the browser in GitHub, Bitbucket or what else hosts the project.

    I write code with emacs. I could turn a file in read only mode but I prefer not to mix what I'm working on with what I'm only reading.

  • by foobarandlmj on 7/30/2022, 10:25:23 PM

    see: https://github.com/CoatiSoftware/Sourcetrail , even tho the project is marked archived, it's pretty solid, i personally still use a 2019 release.

    i also have a self hosted instance of this : https://elixir.bootlin.com/linux/latest/source

    what you asked, comes across with code auditing as well, i wasn't surprised to know security researchers use sourcetrail as well.

    hope your favourite language is supported.

  • by neutered_knot on 7/30/2022, 10:51:01 PM

    I do code review for legal cases on occasion. When I do, and when possible as sometimes the tools I can use are specified before I get the job, I like to use doxygen (https://www.doxygen.nl/) to convert the code to html. It also creates call graphs.

    It is nice because it links to function and method definitions where it can, so as I go through the code I open each function I am teaching in a new tab - the open tab set simulates the call stack.

  • by MatthiasPortzel on 7/30/2022, 8:47:49 PM

    If it’s a project I already have open in VS Code, I won’t use a separate tool.

    If it’s a single file I want to check out, I have an alias for “nvim -R” which I use a lot. Vim’s syntax highlighting is very good, prevents me from making accidental changes, and is very convienent if I’m in the terminal already.

    If I’m looking at code on GitHub then their code-search feature is very cool (cs.GitHub.com or by pressing cmd+shift+f on GitHub).

  • by mellosouls on 7/31/2022, 12:39:17 AM

    Not quite what you're asking but once I've narrowed down a code base to the particular area of interest, I use an old school method for grokking:

    Print the relevant sections off to read and use pen to mark and note against them; I find it extremely useful (and less tiring on the eyes) for linking functions and clarifying code.

  • by busterarm on 7/31/2022, 7:24:50 AM

    Not an application but a process:

    1) Run it. See what it does.

    2) Read it. Identify main function(s).

    3) Trace it. Use a debugger w/ breakpoints for this. See if you can follow how it runs.

    4) Print it. Review interesting parts that you don't quite understand away form a computer.

  • by water8 on 7/30/2022, 8:28:18 PM

    Find and grep.

    I don’t understand what is special about what you’re describing that isn’t done in hundred different IDEs

  • by bitwize on 7/31/2022, 2:35:57 AM

    C-x C-r (in Emacs)

  • by f0e4c2f7 on 7/31/2022, 1:37:48 PM

    Less, grep.

  • by ilaksh on 7/31/2022, 5:41:54 AM

    GitHub?