To extend the coding style guide outline thought I would write about the sizing of procedures and files. The short version is that both should be small.
Procedures should be small enough to fit comfortably on a screen. Each procedure should go into its own file. There might be an exception for non-exported helper procedures used solely by the procedure. Longer procedures tend to have redundant code, something that rarely is a benefit.
Similarly, a file should be small. One reason is that helps the compiler/linker produce smaller programs. A compiler converts a file into an object file, with definitions of the data, variables and procedures, which data, variables and procedures it provides (exports) and the data, variables and procedures that it needs. When the linker includes the object file ' because it provides something else that someone needs ' it often has to include a bunch of other object files that define the data, variables and procedures that the first needs. And so on.
But there is a two other practical reasons as well. First, it makes it harder to manage the dependencies of files. Files, and their contents, tend to get reused across projects. It is harder to reuse a big catch-all file. The procedures (and types in the file) depend on other procedures, variables, types, etc. which will need to be 'reused' as well. (Or defined). Even if the aforementioned procedures are not actually used by the new project (that is, they are 'dead code.').
Second, big files are harder to manage changes in. When a file has lots of procedures in it, it tends to be a focal point for multiple developers to make changes in. This makes it very hard to merge changes between the developers. Which leads to a tendency to merge in changes before the developer has fully worked them out on the desk. (This habit in turn leads to pretty poor quality of the final product). It also tends to encourage 'locking' the file, stalling independent development.
In other words, big procedures and big files are poor modularization. They lack clean independence, and ripple problems out for a long time.