|
|
|
|
|
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. |
|
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.