I think this is a pretty good rule of thumb. Does anyone know of any metrics to see how an individual codebase does in this regard by looking at PRs/commits? I

I think this is a pretty good rule of thumb. Does anyone know of any metrics to see how an individual codebase does in this regard by looking at PRs/commits? It is largely because of this reason that I disdain patterns which separate things out into top level folders like /views, /reducers, /actions, /utils. Most code should be organized at the feature level with separate modules for global utilities (which are always hard to organize). I think this methodology works well because more files means more mental overhead and context switching, particularly for code reviews. The best code review given a reasonably sized change (not 20kloc) is a single file where the file contains little not relevant for the changed code. Not only is it easier to comprehend, it also avoids unnecessary merge conflicts.