Open sores

Is there a tool to visualize how code interacts with each other in big projects?
How else are you supposed to get an idea of whats going on without reading the entire source.

Other urls found in this thread:

github.com/universal-ctags/ctags
github.com/rakshasa/rtorrent
gnu.org/software/cflow/
twitter.com/AnonBabble

remove one part, then try to compile other parts and look where errors occur.

For you, Sublime Text
Go to your favorite designated street and beg others to do the work for you. You've already got that part nailed down :^)

It depends on the language.
You might be able to use graphviz to create a function call graph. I did that once for a big Perl codebase I took over.
Also, stack traces help a lot. Make a function that outputs a stack trace to screen or a logfile, and then just call it from wherever you need when you're confused.
Either that or run the whole program in debugger and set break points.

Also forgot to add: cscope is very useful for C, as is ctags in general (most editors make use of that). ectags is the equivalent for other languages.
Vim also has a plugin that shows all the existing functions (I guess from parsing tags file) in a sidebar, which can be useful. Emacs probably has similar thing.

I-it's not like I wanted to study it or anything.

Do you know of any small yet usable terminal which code isn't a clusterfuck this big?

st, obviously. Replaced urxvt for me.

suckless.org code in general is pretty easy to read.

Either you ask someone for guidance or you have autism superpowers, that's the only explanation I have. In my own projects I have documentation up the ass because I just cannot keep everything in my head. Without documentation I wouldn't be able to navigate through my own code six months later. It's not like my code is spaghetti, but I need some sort of map to know where I can find a particular thing instead of having to dig through everything. It doesn't have to be a full-blown document, just having a short readme at the root of important directories is good enough.


exuberant-ctags used to be the de-facto ctags program, but it has been unmaintained for a long time. universal-ctags is its modern successor:
github.com/universal-ctags/ctags

...

You can substitute random for really any given OSS project. None of them have diagrams or UML stuff explaining anything.

All codebases open or not take some time to understand. First place is look at the build configuration files, and in them find out what file contains the first thing initialized.

It varies by language and conventions; usually something containing the words "main" or "init".

You go into that file and start looking what starts what when and in which order, and with that you should get a rough idea of how the application is structured.

If you can't understand after that, the problem is either your understanding of the ecosystem, the codebase structure or simply the time you invested into the task being enough. Some projects are inherently more complex than others and can't avoid a little complexity to remain somewhat sane.

Welcome to the world of progamming with other people, same as love: sucks at times, but it can sure beat doing it alone.

Diagrams are a sign of a bad codebase. If you need one to understand it in a reasonable amount of time, you have to invest time into refactoring. Right now.

Instead of UML diagrams and tons of text, use descriptive variable, function, and module names. Then some short comments here and there when it's not obvious what something does.
Other than that, a basic design doc that includes the purpose of each module, and how error handling is done. No need to go all crazy with it though. Besides, you have to maintain that text, just as the code, and keep them in sync.
Having some unit tests is nice too.

I see some valid criticism in here so let's provide a real world example.

Suppose you have to add another view to rtorrent.How long would it take YOU to understand enough of its codebase to accomplish that taskgithub.com/rakshasa/rtorrent

GNU cflow can be fairly useful, but it's not terribly complex or flashy. It breaks down a function into the other functions it calls and draws it in a tree.

gnu.org/software/cflow/

It's also quite easy to compile yourself, from what I remember.

Compared to urxvt? Literally anything

Which is great because it makes adding stuff to the terminal to suit your needs much easier. Another user on here had mentioned how he had expanded it to read a config file when he wanted to change colors/fonts.

why is the rtorrent code such shit?

Made by one person.

(In C++)

Is there anything like that for c++?

Oh, I assume if it was written in some obscure lisp dialect it would be the epitome of readability?

a::lisp::would->(likely).)~>::more::readable::andeven>>more::elegant()

Disgusting.
I hope lisp continues to be fringe and will never make it into the mainstream

That's C++ syntax. (This is (what lisp) (syntax) looks like)

Neither of those are actual arguments that explain this shit code.
This is pretty ironic

I write lisp code 24/7.

You are also an unemployed basement dwelling NEET