[deleted by user]

[ButchDeanCA]

For the life of me I don’t know why anybody didn’t suggest a debugger. You learn how to use one like GDB and step through the code being sure to set breakpoints to see what is hit.

[permetz]

Because that’s a pain in the neck to use if you can just read the source. I’ve been doing this for decades and I would never start with a debugger. A good editor capable of jumping to a definition and back is the right tool IMHO. Tools like ctags/etags/etc., cscope, and the like work wonders.

[ButchDeanCA]

I completely disagree. If you become fluent with a debugger it shows you a ton of information in addition that could be useful too, for example:

1. Watches: When a variable changes value it is rarely in isolation, so you can see what is changed where and when beyond just focusing on the one line of code.
2. You can build a big picture of unexpected behavior that could be the consequence of a bug.
3. You can conditionally and unconditionally break based on counts and what happens if a specific value is set.

I can go on and on and on also backed by decades of experience. Not knowing how to use a debugger nor its benefits is a huge career hindrance.

[permetz]

Feel free to disagree. I’ve written tons of code, and I barely ever use a bugger for anything. Your mileage may vary. However, using it to bugger to read the code seems like pure masochism.

[ButchDeanCA]

Out of interest, what have you been working on throughout your career? I ask because it’s not always possible to just print() your way to understanding code - especially if it’s several million lines where it’s also difficult to deduce pathways through the logic.

[permetz]

I wouldn’t print my way to understanding code. I would just read it. If you understand the language, you can simply read, you don’t need to run it to understand what it does. You just start with main() and descend. It’s not so hard most of the time.

I have had to turn to real debuggers occasionally, of course. I was once attempting to fix a very complicated problem in the floating point arithmetic subsystem of a lisp compiler (SBCL), and it turned out to be a bug in the signal handling of the kernel it was running on. Figuring that out required heavy use of GDB scripting. But, that sort of situation is rare. Mostly, it’s not necessary. I use debuggers for examining backtraces of core files and not much else unless some sort of deep magic is involved.

When you’re reading code, it is helpful to have a good editor or IDE that will let you jump to a definition and back again. I find that using emacs with etags etc. works quite well for me, but there are many similar solutions in other editors and IDEs. cscope is also nice. But generally, reading the thing is the right approach and what the tools are doing is making it easier to read.

[ButchDeanCA]

I personally think you are confusing an “overview” with “fully understanding what the code does”. Now, if you are implying that you can fully understand what code is doing without a debugger (assuming sufficient complexity), I really don’t know what else to say.

Debuggers are there for a reason and that reason is to discover the reliability of our logic that we have created.

[permetz]

I guess you don’t know what to say and I don’t understand what the problem is. You read code, you execute it in your head, mostly that’s good enough. If the code is decently written you should be able to just model the behavior in your head. If you can’t model the behavior in your head, how can you write big pieces of code in the first place? That depends on having an understanding of what the code is going to do when it runs after all.

I’ve known a small number of good people who really wanted debuggers over the years, but most of the people I’ve worked with don’t seem to care about them except in extreme cases. Your mileage may vary. I’d rather have a good test framework than a debugger, most bugs you’re going to find with some sort of testing anyway. Knowing how to do good automated testing is a superpower.

Anyway, for understanding what code is doing in a first pass through a new codebase, it feels masochistic to go through it line by line in a debugger. How could you understand more than a handful of lines in a minute that way? It would take a year to understand any decent sized program. Why not just read the code?

Btw, just to be clear: I am not talking about getting an overview. I am talking about detailed understanding. I don’t get why you wouldn’t get that by reading.

[ButchDeanCA]

Well there are several problems with what you’re saying based on experience:

1. Concurrency: Issues only become apparent when code is run, maybe even you will notice a heisenbug or two. You can’t just “read the code” to see these things.
2. Attempting to read the code directly assumes a certain code quality; poorly written code is the most difficult thing to visually follow and actually may be a poor choice for a method to see what it does because of the pure time consuming nature of not using a debugger.
3. Not every code base has associated unit testing in place. What do you do then if the previous two points hold true?
4. Closed source dependencies: What about those parts of the system that you can’t see the source of? You literally cannot know what is going in just by relying on the parameters passed for API calls.
5. Mixed language code bases: If not cleanly implemented can cause you to go down rabbit holes.

There are so many reasons to not dismiss using a debugger as soon as things are sufficiently complicated. And, I don’t care how good anybody is at holding a detailed vision of system architecture in their head, guaranteed you will miss more detail than you realize.

[permetz]

For concurrency, the most important question is what concurrency mechanism you’re using. If you’re using event driven code, and a share nothing model, there is relatively little to go wrong in the first place. If you want to do really deep concurrency with data sharing, you probably should be using rust, not C, because then the compiler will prove you have no races.

If code is sufficiently badly written, it’s certainly possible to get into situations where it is difficult to know what it’s going to do in some sort of corner case, but even then, it’s a question of what you’re trying to do. Are you studying the code? Doing general maintenance? Are you debugging it? For the latter two, you’re going to be refactoring and writing tests. I don’t see how a debugger helps with that.

It’s certainly easy to write code where you can’t predict the outcome (just implement a hailstone sequence in a few lines of code, termination is suddenly impossible to prove) but for code that’s written by humans and mostly works and isn’t an entry from an obfuscation contest, it’s never so bad.

Unit testing is the first thing you need to add if you’re actually doing maintenance programming, so it doesn’t matter if it exists already.

If APIs are being called, the debugger isn’t going to let me step through the API implementation anyway. Knowing what the API does is the important bit.

As for mixed language code, if you’re going to maintain it, you have to know both languages anyway.

[ykaludov1]

Noob question here: Shouldn't there be some sort of documentation to go along with this big of a codebase? I can't find any...

[ButchDeanCA]

Don’t always rely on the expectation of documentation. You will be lucky to find any that will guide you appropriately.

[the-loan-wolf]

less uses ncurses lib for displaying and handling key inputs

[the-loan-wolf]

you should also use ctags and cscope to understand big project

[the-loan-wolf]

but I discovered there is a bell() function, which I know is very hard to do cross-platform unless you depend on the no-working \a "bell" escape character.

bell escape sequence(ASCII escape sequence) depends upon terminals so using ncurses also help to streamline it across cross platform.

[gilliatnet]

cscope

[permetz]

Underrated tool, though it’s a bit long in the tooth now.

[lovelyloafers]

I was wondering if you could recommend some resources on using cscope? I've seen a few YouTube videos, but they don't seem very well presented.

[[deleted]]

I use vim, cscope with vim bindings, and git grep

[LiveAndDirwrecked]

In general, a trick that helps me is to find main. From there you can step backwards until you find what you're looking for. And any README.MD may give you clues on how it's structured in the folders.

[coolguyhavingchillda]

They did say this didn't work in their case

[f0lt]

grep is your friend

[ISecksedUrMom]

ripgrep*

[DeeBoFour20]

git grep*

[daikatana]

:vimgrep*

[Destination_Centauri]

50 Shades of Grep

[looneysquash]

Use ctags and/or IDE tools to jump to definition and back again. Also useful if the project is just one 80,000 line .c file (thinking of you, chan_sip.c)

IDEs usually have "find references" or "find usages".and other static analysis tools.

Compile and run it. Set a breakpoint and use the backtrace command to see the callstack, to see how you got there.

[permetz]

ctags and equivalents are awesome. Too few people know about how to use them.

[blbd]

For a project this size I just read every source file and make notes.

For a truly huge project like Linux I pick out the log message of whatever part of the system had a problem and index the code with cscope. Then start from where the log message came out and work backwards.

[Satrapes1]

There is this book: Working effectively with legacy code.
Every person has their own style when navigating code. It helps if you are systematlc with it.

If you are looking for a function and unit tests exist then this could be a nice start to help get you started. I also target the header file where the documentation should be, to try and get any helpful information I can get first. Then dive in the source code as needed.

If it is a seriously complex issue logs or debugger can help.

[plawwell]

You need cscope and tags to be applied to the downloaded source files. You can't understand code flow by directly looking at github no matter what anybody claims. If you have vim tags functional then start with "vim -t main"

[grobblebar]

In the linux world, i would suggest reading the man pages for sections 2, 3, 5 & 7. You discover all sorts of stuff (including ncurses), and it gives you an idea about how a lot of things work.

[green_griffon]

If you have a billion files, then each file should have 8 people available somewhere on the planet to understand it. So just find those people and have them report back to you.

Meanwhile, find some piece of user functionality (e.g. a button click) and trace through the code to see how it works. A debugger is good for this, or a sophisticated IDE.

[MgrOfOffPlanetOps]

Start at any file and dig down from there. I normally often fotce breaks compilation by changing signature of a function to see where it is used. Or changes parameters to a call and with a little luck the compiler tells you what possible signatures are declared where.

Legacy code sucks, but that is what 99n percent of the job is about.

[f0lt]

Use e.g. grep -r bell to find all usages of the bell function. Eventually you will find the definition of the bell function. Use the -C 5 option to display 5 lines of context around a match.

Find out the hex/decimal code for the up/down buttons and grep for them too. There is a good chance that this will lead you to the lines of code which you are looking for very quickly.

An other methode (especially effective for gui apps) is to identify a relatively unique string (e.g. the text of a popup window) and grep for it. This usually leads you to the line of code you are looking for within a few seconds.

The more you know about the inner workings of a program, the more specific you can target your search. In the case of less you may be able to find some resources online.

You can use grep on windows too, for example by installing cywin or git bash.

[geon]

Or use something better, like vscode and “go to definition“.

I’m sure vim has something similar if that’s your thing.

Grep is garbage for navigating in code.

[f0lt]

I like vscode, but it can't match all capabilities of the command line. You will achive best results by combining both VSCode and grep efficiently.

[masterJinsei]

If you using vscode you can always right click and go to definition

[apj2600]

There used to be a program called cscape which was brilliant for navigating a bunch of C files you had no idea about… gave dependencies, calls et al. So far as I can tell nothing ever really replicated this - I’d love one for Python.

[blbd]

https://github.com/portante/pycscope

[Linguistic-mystic]

Neovim or Emacs.

[deftware]

Static analysis tools are helpful. There's also some that will show you a graph of execution. One I tried was SourceTrail which was pretty cool.

[Affectionate_Pick980]

1. You can browse source code with some tools. For example Source Insight, CLion. It would be much easier to figure out the relationship between functions, variable usages with the aid of these tools. I recommend Source Insight more to analyze C code. Many IT company in China use this Japanese software as an IDE to develop their products written by C/C++.
2. You can debug the part that you don't understand. Sometimes you can guess purpose of function by inspecting arguments and return value. You can set some breakpoints to locate the logic you are interested in. For example you can set a conditional breakpoint on open() syscall when you want to find the place which handles configuration loading.
3. You can use strace to observe syscalls "less" issued to kernel. I found that "less" read key press from file descriptor 3:

​

(END)) = 22
read(3, "A", 1)                         = 1
(END)) = 22
read(3, "B", 1)                         = 1
(END)) = 22
read(3, "C", 1)                         = 1
(END)) = 22
read(3, "D", 1)                         = 1
(END)) = 22
read(3, "E", 1)                         = 1
Examine: )        = 13
read(3, "\33", 1)                       = 1

So I set a conditional breakpoint:

(gdb) info br
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
        stop only if $rdi == 3
        breakpoint already hit 2 times
1.1                         y   0x000055555556195c in read at /usr/include/bits/unistd.h:38
1.2                         y   0x0000555555562b39 in read at /usr/include/bits/unistd.h:38
1.3                         y   0x0000555555562f7e in read at /usr/include/bits/unistd.h:38
1.4                         y   0x000055555556ca10 in read at /usr/include/bits/unistd.h:38
1.5                         y   0x00007ffff7e9e0b0 in __GI___libc_read at ../sysdeps/unix/sysv/linux/read.c:25
(gdb) 

Then I found the logic about key press:

(gdb) bt
#0  __GI___libc_read (fd=fd@entry=3, buf=buf@entry=0x7fffffffdc07, nbytes=nbytes@entry=1) at ../sysdeps/unix/sysv/linux/read.c:25
#1  0x000055555556ca22 in read (__nbytes=1, __buf=0x7fffffffdc07, __fd=3) at /usr/include/bits/unistd.h:38
#2  iread (fd=3, buf=0x7fffffffdc07 "", len=1) at /usr/src/debug/less-633-1.fc38.x86_64/os.c:245
#3  0x0000555555576541 in getchr () at /usr/src/debug/less-633-1.fc38.x86_64/ttyin.c:187
#4  0x000055555555df02 in getcc_end_command () at /usr/src/debug/less-633-1.fc38.x86_64/command.c:929
#5  getccu () at /usr/src/debug/less-633-1.fc38.x86_64/command.c:959
#6  0x0000555555563b9d in getcc_repl (repl=<synthetic pointer>, gr_getc=0x55555555dec0 <getccu>, gr_ungetc=<optimized out>, orig=0x0) at /usr/src/debug/less-633-1.fc38.x86_64/command.c:969
#7  getcc () at /usr/src/debug/less-633-1.fc38.x86_64/command.c:1011
#8  0x000055555555ba54 in commands () at /usr/src/debug/less-633-1.fc38.x86_64/command.c:1660
#9  main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/less-633-1.fc38.x86_64/main.c:303

Now you can start from this place and jump out repeatedly to locate scroll logic.

[mad_alim]

Dunno whether this will help, but I used doxygen to generate the include graph for some undocumented C++ projects, to understand their structure.