really... if you've ever tried to write your own functionality into something like wordpress or bootstrap or whatever, you'd rather have that all in a single code file with less white space or comments? Would that make it easier to change the positioning of a particular dialog box? I thank God all the time for the white space and long comments left by writers of those kinds of libraries. Maybe those seem like trivial examples, but they're huge libs that don't often need a lot of changes; yet when you need to change things, they make it quite easy to find.
[edit] as I wrote that, I just realized that younger devs might actually look in horror on the idea of directly editing libraries like that for particular deployments because the tooling or shop mentality so forces automated upgrades that could overwrite custom changes... and institutional memory being so short, no one might remember the change some dev made to a bootstrap file. heh. But that's like someone calling themselves a mechanic without ever modifying an engine. You write a note, commit it with a custom marker like #weModifiedThis, and don't upgrade the library for 15 years or until you're dead or retired or the company goes out of business. Done.
There's a balance to being overly verbose and isolating _EVERYTHING_ from _EVERYTHING_ to such a degree that it's a major travel all around the codebase to follow one little path through a single call, and cramming _EVERYTHING_ into one file.
This is true and reasonable for small systems and code bases, and small teams. But it’s not generally a good idea to argue for a relaxed balance in large systems or code bases, nor with large teams, where you can travel all around the codebase via roads you built and mapped, or you can travel all around the codebase following bugs into code you don’t know caused by lack of isolation. Eventually, if you don’t isolate, then there’s no avoiding traveling all around the codebase, it’s just whether you want that to be a pleasant journey or not. Of course it’s really hard to argue over programming platitudes without any specifics in front of us to discuss, but chances are high that experience over time with large systems on large teams will make you reflexively avoid arguing for balance when it comes to either comment verbosity or code isolation.
[edit] as I wrote that, I just realized that younger devs might actually look in horror on the idea of directly editing libraries like that for particular deployments because the tooling or shop mentality so forces automated upgrades that could overwrite custom changes... and institutional memory being so short, no one might remember the change some dev made to a bootstrap file. heh. But that's like someone calling themselves a mechanic without ever modifying an engine. You write a note, commit it with a custom marker like #weModifiedThis, and don't upgrade the library for 15 years or until you're dead or retired or the company goes out of business. Done.