Comment by swang | Hacker News Reader

Comment by swang | Hacker News Reader

Parent Full thread

one of my biggest issue with looking through codebases is, where do i start?

if i'm not familiar at all with the language, or more specifically how the language architectures the program, i'm just going to be spending a lot of time looking at stuff that probably isn't the meat and bones of the library/app.

take for example, his first suggest codebase, seastar. i haven't done c++ in years (school, using turbo borland) so where do i look? "apps" maybe? nope just seems to be a folder of libraries. ah, probably the core folder. whoops there are 20+ files/headers. should i dig into this assuming that's where most of the code for the app/library is?

i suppose it would probably be nice if there's a site that explains how most programming languages layout their code. e.g) javascript generally is laid out similarly now, as is ruby/rails. so a site to explain the general layout structure would be kinda cool. it's kinda late at night so maybe i'm overthinking this.

Search for "Code Review" posts by the author of the "Game Engine Black Book":

http://fabiensanglard.net/

He walks you through his whole code review process starting from cloning/building the project:

http://fabiensanglard.net/doom3/index.php

http://fabiensanglard.net/quake2/index.php

Well there goes the rest of my productivity today. I love reading these.

For what it’s worth, this is how I usually go about exploring codebases ( I am the author of that blog post ).

I either have something specific in mind that I want to understand, e.g in the case of Seastar, I wanted to understand their reactor design and implementation, so I locate the respective file(s) that implement them and I start from there, and then I just branch out to other files -- I usually keep multiple vim windows open, and I take notes.

When I am not looking for a specific answer, I choose a directory, and then I sort its files by size (e.g ls -lShr *.{h,cpp,hh,cc,java} ). I usually sort by file size in descending order(smallest first), but some times it makes more sense to sort by largest file first, and I start from there. I still map my way around, and if something stands out, I open the respective file in another vim window/tab, and look it up, and then continue with the previous file.

You can also make a git script to check what files are the most modified.

I also have a script that checks what are the most crypto-y file in a directory.

> I also have a script that checks what are the most crypto-y file in a directory.

Could you share it? :)

First and foremost, clone and build it. If you cannot clone, build and get it running within an hour, it's generally crap and not worth your time[0].

Once you get it building and running, you can now start making simple changes in order to find your way around.

[0] Developers should pride themselves on how (relatively)simple this process is for their project(s).

That would disqualify every C++ codebase I've worked on.

One of the quality standards of my company is "devs have rebuilt the project from scratch on their machine, in < 15 min". It is checked weekly and works wonder

This is where I find robustness of Go particularly interesting and it's probably one of the reasons where it gained so much of momentum recently.

If the project is using git, there's a git-extras package to show statistics on the git history where you can see the files that are most frequently worked on.

https://github.com/tj/git-extras/blob/master/bin/git-effort

This is really cool. What are some of your favorite git extras commands?

When in doubt,

    grep -r -- 'main[ ]*(' .

The question to me is, do you really learn anything just by reading it or is it just an exercise in self-aggrandizement and programmer posturing. You will be able to say: I've read that code and understood it. Some people claim that it's more important that you also look at the "bad" code and find ways to improve it that way you'll be truly learning the craft of programming and not just be on board with the latest engineering practices of a particular language and tool-sets.

You know the problem they are trying to solve. I think looking at how they solved it is the definition of learning. I don't think many people read code just for the bragging rights of saying they understood it. That seems silly.

You're right, such things should actually be in the README, but go figure, nobody does it.

Documentation should not be a matter of "every function has a docstring", a description of the architecture is always useful.

I'm with you on this! Clicked on the same suggestion and had no idea where to start. Expected to see a "src" folder which is typically used to separate the source code of the project from the docs/objs/tests/utils, it was missing so I closed the tab not willing to search for each part of the actual code was.

Generally, if it's an executable, you should look for the main function. Otherwise, it's a library, in which case you should look at the documentation and start from the handful of points of entries into the library.

I start with finding entry points and analyzing data structures.

Reply on news.ycombinator.com