Live data from Hacker News

On navigating a large codebase

blog.royalsloth.eu

11–20 of 139 posts

Re: On navigating a large codebase

#11

Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?

I wrote one for Tcl years ago, as I started working on a really complicated product with around 50k lines of code (or more, distant memory).

Maybe I should give it another crack for modern languages - there is an even greater need for it these days with dependency injection and microservices being common.

The way I see it the need stems from needing to understand what is REALLY going on, as opposed to what the code is saying should be going on.

Re: On navigating a large codebase

#12
Just rewrite the dang thing! Planned obsolescence is so important for all of these reasons listed in this article.

Know when its time to kill your services, and have a plan well in advance for how it'll go down, and what will take its place.

Re: On navigating a large codebase

#13

Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?

If you use VS Code with Ruby or Java, check out the AppMap extension. Its core function is similar to what you've described: diagramming execution flow and component relationships. It's dynamic analysis, so it captures data snapshots as well. https://marketplace.visualstudio.com/items?itemName=appland....

Re: On navigating a large codebase

#14

Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?

IntelliJ data flow analysis does this to a certain extent (paid feature though)

https://www.jetbrains.com/help/idea/analyzing-data-flow.html

Re: On navigating a large codebase

#15
I have similar issue and wrote code-scope to tackle the same issue:

Check the demo screencast: https://www.code-scope.com/cs-demos.html

Document the bpfcc tools cross reference Linux Kernel source here:

    https://www.code-scope.com/s/s/u#c=sd&uh=0f2c2fa280a2&h=a2f7c69d&di=35&i=60

A web document that analyze and document the USB driver source code in kernel source tree: https://www.code-scope.com/s/s/u#c=sd&uh=cf979192e856&h=ede5...

It has fast source code search engine and can search any symbols, function in GBs of source base in milliseconds.

Re: On navigating a large codebase

#16
The advice about using both grep /and/ the IDE is very good. Often they are framed as in opposition to each other, but in reality they're just tools. IDE's are great when they work, but it's entirely possible to make it confused.

I keep hearing to get better IDE's, especially from Java developers who seem to have nicer IDE's than us C++ schmucks, but even the best IDE will not save you when your program is really an interpreter for some ad-hoc, unspecified dynamic language implemented on top of YAML or XML.

I highly recommend having shortcuts for both ripgrep, fd and clangd in your editor. Also remember you can use the .rgignore file.

Re: On navigating a large codebase

#17
post #16

The advice about using both grep /and/ the IDE is very good. Often they are framed as in opposition to each other, but in reality they're just tools. IDE's are great when they work, but it's entirely possible to make it confused. I keep hearing to get better IDE's, especially from Java developers who seem to have nicer IDE's than us C++ schmucks, but even the best IDE will not save you when your program is really an…

[deleted]

Re: On navigating a large codebase

#18
An interesting way to approach the documentation issue discussed in this article is 'wiki bankruptcy': when a wiki goes stale, simply tell all devs to save what they think is important before deleting the whole thing outright. Then, they can recreate those pages into a new wiki. Read more about it here:

https://critter.blog/2020/08/10/wiki-bankruptcy/

He also talks about using this 'bankruptcy' philosophy in other aspects of life, which I thought was intriguing:

https://critter.blog/2020/09/24/declare-bankruptcy-and-dont-...

Re: On navigating a large codebase

#19
post #17
post #16

The advice about using both grep /and/ the IDE is very good. Often they are framed as in opposition to each other, but in reality they're just tools. IDE's are great when they work, but it's entirely possible to make it confused. I keep hearing to get better IDE's, especially from Java developers who seem to have nicer IDE's than us C++ schmucks, but even the best IDE will not save you when your program is really an…

[deleted]

I can assure you netbeans will change and then not be your No. 1 java ide.

Re: On navigating a large codebase

#20

Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?

I think this is a fantasy (that many of us have).

"I run this magical tool, and voila! a satellite view of the code!

It clearly shows this river runs into this bay, and there's a dam over there! Now I'm miles ahead of everyone!

Lookie, this river runs in circles..."

Ha.

What really happens is you run some tool and what comes out looks and smells like hair you pulled out of your clogged drain.

I've tried this. Anything graphing shows ... well...

It will look like this:

https://upload.wikimedia.org/wikipedia/commons/9/9b/Social_N...

I think the thing is - the code that gets thing done will confound automated visualization tools.

It's basically like expecting decompiler output to be super helpful. It may help your understanding a little bit, but much will be lost. Yes there are heroic decompiler stories, but time is involved.

Also, most code has macros or helper functions or automatic code generation or something that obfuscates what you're really looking for. You will have to develop a system to unblock this organically.

What will help:

Peruse the source code. Try to follow the flow. if you have tools to jump back and forth between a function call and definition use it.

fix some bugs. Follow the stack traces up and down.

ask people how stuff works. put in the time. and the other stuff mentioned in this article. The osmosis method is really how you'll get it.

Post reply on HN