Hacker News new | ask | show | jobs
by inChargeOfIT 924 days ago
I find if you subscribe to the "Write libraries not software" mantra where your libraries/packages/classes are focused and adhere to the single responsibility principal, code organization kinda sorts itself out. But I agree with the author that organizing and commenting long files like this makes it easier to grok what's going on.

But if you are clicking around a project and scrolling with your mouse, instead of taking advantage of your IDE's ability to use keystrokes to find and open files, jump to references/definitions, find and replace text, etc., you are handicapping yourself. It's worth the investment to learn.

2 comments

> But if you are clicking around a project and scrolling with your mouse, instead of taking advantage of your IDE's ability to use keystrokes to find and open files, jump to references/definitions, find and replace text, etc., you are handicapping yourself. It's worth the investment to learn.

Really? I've observed the opposite.

The developers that I work with that make heavy use of things like fuzzy file matching, go to definition, etc tend to have a _much_ harder time understanding the codebase.

My theory as to why this is the case is that they're never building or taking advantage of any higher level context. Having to browser through the directory structure (assuming it roughly mirrors the code structure), having to look through classes, etc forces you to actually build some awareness of the greater context of that method you're looking at.

Using "go to definition", you may find yourself in a method, then later you hit "go to definition" and find yourself in another method, and unless you've made a conscious effort to observe so, you may very likely have never noticed they're even in the same class and presumably related.

Using "go to definition" you might end up in a "process" method. Knowing that's in the "Image" class in the "ImageResizer" module would probably add a lot of clarity to what that's doing before you even get started looking at code.

When I need to onboard in a new codebase, I very much _don't_ use those tools until I have a solid grasp on the big picture.

I just can't imagine there's any real correlation between a developers ability and their use of specific IDE features.
Yes. I would have liked to add something more, but you have said everything there is to say about this subject.
I try to organize most of my code as libraries too, but I still find having sections and subsections super useful. I sort of took that for granted because most of my code was in Haskell, and the Haskell documentation tool supports sections/subsections/etc natively, so I just used those to organize my larger modules.
I totally agree. And some long/complex files are simply unavoidable (shell/build scripts, config files, etc).