Hacker News Reader

Comment by jcranmer | Hacker News Reader

> But don't just try to get by with basic vim and grep. Learn something better.

I laugh because... I get by with vim and grep (although arguably my vim usage doesn't qualify as 'basic'). I seem to compensate mostly by splaying my stuff over large amounts of terminal windows--apparently needing a dozen different terminals to work on something isn't common? ;-)

View on HN

I got by using vim (or sometimes emacs) and grep for twenty years, but it stopped working when I encountered large codebases written by people who have abandoned (or never learned/embraced) modularity. The current fashion seems to be splattering related definitions and (tiny bits of) code across hundreds of files all over a huge monorepo, with no rhyme or reason or comments. If you can hold such a huge pile of loosely-connected garbage in your head right from the start then great, but I think the common advice should still be to let your tools do the cross-referencing and indexing.

I don't disagree that having a good cross-reference/indexing setup is wonderful. I'm fortunate in that most of the projects I've worked on are sensible enough that I can at least narrow down the couple of locations it might be in, and where it's not so easy, it's at least something where "oh yeah, all the interesting code in LLDB is actually in Plugins/" can easily be slotted in the brain. (glibc is another horrible one)

One of the things I've considered doing is putting together a recording of fixing a bug in a project whose source I've never seen before, as the only way I can think of to explain how to navigate a large code base without accidentally skipping several steps of "I apparently memorized the layout of the monorepo without realizing it". This plan is defeated by... not having a code base I can use for this where I haven't actually poked around its source before at least once.

but then, succumbing and using "tools" because the code is bad, is a sure recipe for rewarding / encouraging people to write bad code, right?

Perhaps, but doesn't choosing not to do so also increase the likelihood that you will be less effective about figuring out what a better solution looks like that is minimally disruptive to production?

I mean if you're skilled enough to do without those tools great =)...

my point is, if you dont flag bad code and fix it during code review because "it's workable when you have the right tools", then that code isn't going to improve, and it will slowly accrue technical debt for which the IDE will no longer be an adequate solution.

but, yes, this is me being idealistic. i get that this probably wont happen much in practice.

So, what should I use instead? I want to start working with huge C codebases. I want a tool that is open source.

Reply on news.ycombinator.com