4 ms·

This was written for readability.

ptaipale 12y ago
I think having many small files is not good for readability. It may be good for reading that one file, but not for understanding the whole.
- vog 12y ago
  I believe this is mostly a matter of taste. I find this style very consistent. Each file deals with exactly one abstract data type, and all functions around it. This is common in many languages. Java enforces one (public) class per file, which is also a common coding style in C++, Python, Ruby and PHP, even though those languages don't enforce that. You also find this in more modern languages like OCaml, where it is recommended to have one "module" per file, and one "module" concentrates on one data type. (and maybe one or two helper types if needed, much like in-class type definitions in C++) This may be unusual in C projects, but it does have its merits. I read the code and wonder "Oh, what exactly is that 'dict' stuff?". Then, I can blindly guess the file names "dict.h" and "dict.h". I see a full explaination of "dict" and nothing else. I then notice that it is a combination of "map" and "vector", and maybe that's all I need to know. If not, I dig into "map.c" and "vector.c". Otherwise, I'd have to search, and finally find it in some unrelated file name like "utils", "utililities" or "mapvectorutils". Then I have to search for all dict-relevant code in that file, skipping through a bunch of unrelated code. To get the "whole picture", I'd prefer to see a simple diagram (autogenerated by IDE, or as part of the docs) that shows which module depends on which other module, maybe somehow arranged into layers. The other strategy "group multiple modules into a file" may convey the highest level quite well, but utterly fails to explain the dependencies of the modules inside a single file.
  - barrkel 12y ago
    Your text search skills or tools are lacking, then. In an IDE, "go to definition" solves this problem. In an editor, incremental text search over the entire project solves this problem (I normally use helm-git-grep in emacs). I'm a fan of bigger and fewer files. Atomized bits of functionality are tedious to read, when you have to read lots of code to understand the gestalt.
    - vog 12y ago
      > I'm a fan of bigger and fewer files Indeed, this is mostly a matter of taste. Both styles have their merits and downsides. For some projects, I also preferred bigger files up to single-file solutions, which also worked great. > In an IDE, "go to definition" solves this problem. In an editor, incremental text search over the entire project solves this problem When using the right tools, it doesn't matter how the code distributed across files. But I believe this is slightly out of scope for the question at hand.
    - vog 12y ago
      > Your text search skills or tools are lacking Ad Hominem should have to place at HN. Please don't do that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - barrkel 12y ago
        If you seriously need lots of tiny files in order to find code, it is a fact that you don't know how to use the tools you have available. That's my professional opinion.
        vog 12y ago
        > If you seriously need lots of tiny files in order to find code Nobody said that. Please read more carefully, especially before goofing off others. Or, simply don't goof off anyone in the first place.
  - rui314 12y ago
    Another reason why I prefer this style is modularity. Each file does only one thing (in this compiler a file is a compiler pass or defines a data structure) and exposes only a limited set of functions. Other functions are marked as "static" to get a file scope. The shorter a file, the narrower the scope. You of course need to achieve the right balance between number of files and size of each file. The current status feels the right balance for my taste.
    - andrewchambers 12y ago
      Without even looking inside the files, you can find the map, set, and list definitions. Needing to look into a file called "utils.c" or "datastructures.c" is less clear than what it is currently imo, so I support your design.
- dmytrish 12y ago
  Yes, it's terrible to have a myriad of files each of fifty sparse lines. "Modern" languages like Java/C# tend to scatter code over many small files. I think it's a cultural thing: since IDEs do not have "split" mode that provides several views to different parts of the same file side-by-side (like Vim does), programmers tend to split code into files small enough to scroll fast and IDE handles switching between files. Plus the dogma "one class, one file" that limits file size even if it's not helpful. I'm glad that functional programming is on the rise: it divides code units more naturally with modules of functionality, not a one-size-fits-all programming language structure like classes. P.S. Also, composition of a big source code file conveys some "background" information you'd have to recover from a needlessly fragmented pile of small files.
  - vog 12y ago
    > I'm glad that functional programming is on the rise: it divides code units more naturally with modules of functionality I'm not sure this will change anything. For instance, OCaml's modules are usually a bunch of functions surrounding a single abstract type. This is very similar to classes in other languages.
  - JasonFruit 12y ago
    On a complete side note, I was going to tell you that myriad is an adjective and should not be used in the construction, "a myriad of". But then I looked it up; apparently I was wrong, and so were the many other people I had heard that from. Thanks for teaching me.

I think having many small files is not good for readability. It may be good for reading that one file, but not for understanding the whole.

vog 12y ago
I believe this is mostly a matter of taste. I find this style very consistent. Each file deals with exactly one abstract data type, and all functions around it. This is common in many languages. Java enforces one (public) class per file, which is also a common coding style in C++, Python, Ruby and PHP, even though those languages don't enforce that. You also find this in more modern languages like OCaml, where it is recommended to have one "module" per file, and one "module" concentrates on one data type. (and maybe one or two helper types if needed, much like in-class type definitions in C++) This may be unusual in C projects, but it does have its merits. I read the code and wonder "Oh, what exactly is that 'dict' stuff?". Then, I can blindly guess the file names "dict.h" and "dict.h". I see a full explaination of "dict" and nothing else. I then notice that it is a combination of "map" and "vector", and maybe that's all I need to know. If not, I dig into "map.c" and "vector.c". Otherwise, I'd have to search, and finally find it in some unrelated file name like "utils", "utililities" or "mapvectorutils". Then I have to search for all dict-relevant code in that file, skipping through a bunch of unrelated code. To get the "whole picture", I'd prefer to see a simple diagram (autogenerated by IDE, or as part of the docs) that shows which module depends on which other module, maybe somehow arranged into layers. The other strategy "group multiple modules into a file" may convey the highest level quite well, but utterly fails to explain the dependencies of the modules inside a single file.
- barrkel 12y ago
  Your text search skills or tools are lacking, then. In an IDE, "go to definition" solves this problem. In an editor, incremental text search over the entire project solves this problem (I normally use helm-git-grep in emacs). I'm a fan of bigger and fewer files. Atomized bits of functionality are tedious to read, when you have to read lots of code to understand the gestalt.
  - vog 12y ago
    > I'm a fan of bigger and fewer files Indeed, this is mostly a matter of taste. Both styles have their merits and downsides. For some projects, I also preferred bigger files up to single-file solutions, which also worked great. > In an IDE, "go to definition" solves this problem. In an editor, incremental text search over the entire project solves this problem When using the right tools, it doesn't matter how the code distributed across files. But I believe this is slightly out of scope for the question at hand.
  - vog 12y ago
    > Your text search skills or tools are lacking Ad Hominem should have to place at HN. Please don't do that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - barrkel 12y ago
      If you seriously need lots of tiny files in order to find code, it is a fact that you don't know how to use the tools you have available. That's my professional opinion.
      - vog 12y ago
        > If you seriously need lots of tiny files in order to find code Nobody said that. Please read more carefully, especially before goofing off others. Or, simply don't goof off anyone in the first place.
- rui314 12y ago
  Another reason why I prefer this style is modularity. Each file does only one thing (in this compiler a file is a compiler pass or defines a data structure) and exposes only a limited set of functions. Other functions are marked as "static" to get a file scope. The shorter a file, the narrower the scope. You of course need to achieve the right balance between number of files and size of each file. The current status feels the right balance for my taste.
  - andrewchambers 12y ago
    Without even looking inside the files, you can find the map, set, and list definitions. Needing to look into a file called "utils.c" or "datastructures.c" is less clear than what it is currently imo, so I support your design.
dmytrish 12y ago
Yes, it's terrible to have a myriad of files each of fifty sparse lines. "Modern" languages like Java/C# tend to scatter code over many small files. I think it's a cultural thing: since IDEs do not have "split" mode that provides several views to different parts of the same file side-by-side (like Vim does), programmers tend to split code into files small enough to scroll fast and IDE handles switching between files. Plus the dogma "one class, one file" that limits file size even if it's not helpful. I'm glad that functional programming is on the rise: it divides code units more naturally with modules of functionality, not a one-size-fits-all programming language structure like classes. P.S. Also, composition of a big source code file conveys some "background" information you'd have to recover from a needlessly fragmented pile of small files.
- vog 12y ago
  > I'm glad that functional programming is on the rise: it divides code units more naturally with modules of functionality I'm not sure this will change anything. For instance, OCaml's modules are usually a bunch of functions surrounding a single abstract type. This is very similar to classes in other languages.
- JasonFruit 12y ago
  On a complete side note, I was going to tell you that myriad is an adjective and should not be used in the construction, "a myriad of". But then I looked it up; apparently I was wrong, and so were the many other people I had heard that from. Thanks for teaching me.