5 ms·
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.
by 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 agoYour 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 agoIf 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 agoAnother 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 agoWithout 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.