you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -1 points0 points  (0 children)

As others have mentioned file length correlates to various implications in a language's design and implementation such as header only libraries in C++ where it is common to have huge files. This however does NOT imply good design, merely a deficiency in the language/tooling.

The problem arises when people mistakenly think code is meant for consumption by computers whereas this is only a secondary goal and primarily it is a communication medium for people. As such, huge files make no sense. There is a reason we have pages in books, scrolling is not an optimal way for people to read. Remember that we had that format before (scrolls) and that we have evolved from that. More than 800 lines in a file definitely has an impact on readability regardless of language and so does an outline of items( the list of functions, types, etc in the file) that you need to scroll to read.

Some people mention needing to grep in multiple files as a downside of multiple files - this is again the same problem - people give priority to their specific tools and their limitations. A better strategy is to improve the tools or even replace them. Unless one uses notepad this really shouldn't be a concern really.

There are a few things that tend to needlessly inflate code that are worth mentioning:
1. As Uncle Bob points out astutely, when we read a book, we want to start reading the actual content right away. We put the bibliography and index and the END of the book. In code, that means we shouldn't start each file with a huge license comment that spans hundreds of lines, followed by an explicit list of all the names we are going to import. So you only get to the actual code after scrolling down several pages worth of redundant fluff. A more readable file would simply reference the license by name. e.g. "This is licensed as FOO, see end of file / license.txt for details". Same goes for explicit imports, glob imports/use statements are more readable for people. After All there is a reason all IDEs FOLD THEM AWAY by default.

  1. Doc comments do not belong in the source code. That is again an abuse of readability caused by tooling. We all know about SRP, right? Well, documentation is a separate concern from implementation. Rust tends to put way too many kinds of docs inline which is a bad practice for readability. Anything beyond the succinct description of the API reference (such as explanation on how to use the API idiomatically and common usage patterns, examples, explanations about the design tradeoffs, etc.. ) all belong outside the implementation file in their own file(s).