For the past few years I spent quite a lot of time pondering the topic of code organization. Where does this file go? Do we split the files by architectural layers or by business areas? That sort of thing.
A few days ago, when doing something completely unrelated, an idea popped into my mind and I'd like to share it with you.
What if, instead of (or alongside) putting files into a single, fixed layout of directories, we simply tagged them (just as we do with posts on DEV) and then based on these tags we could create all the layouts and hierarchies that we find useful?
The tags and layouts could be specified in some sort of file in our repo, say in JSON or YAML:
{
"tags": {
"controller": ["src/controller/user-controller.js", ...]
...
},
"layouts": {
"layers": ["controller", "model", "view"],
"domain": ["orders", "catalog"],
...
}
}
Then, based on the tags and layouts that we specified, our text editor/IDE could allow us to conveniently browse the files:
What do you guys think? Would it help you organize your code? Or maybe it solves a problem that's only in my head and nobody else cares?
Also, let me know if something like this already exists. I tried searching online, but apparently I used the wrong search terms.
Top comments (15)
WinFS, a project that was scrapped, was supposed to be a semantic file system, in which metadata (structured or unstructured) was to be the center of all.
I think it was canceled because it was too complex to understand (it wasn't just a tag based file system, but an entire metadata based storage system, with a relational DB inside).
Legend says that Spotlight for macOS stems from that idea.
If you have Linux you might want to take a look at TMSU, it allows you to mount a virtual file system using tags
A commercial product called M-Files has actually implemented this. Until a few years ago i used it daily, and it is great. That said it was Windows only, so that was quite a big limitation.
Demonstration: youtu.be/seTjogkSApc?t=42
That said, I see this as a hard thing to implement as the primary file system. It took a long time for some people to get the idea that the same document was in many different "folders" at once.
I wonder if WinFS and/or Spotlight were inspired by BeOS' BFS, which had some pretty interesting database/search characteristics. Truly an OS before its time!
Could be, don't know... BFS seems to be ahead of its time in a way
From the link in your comment:
LOOOL, times have changed.
I usually have developers that I'm interviewing come up with a data model for a file system - then I ask them to come up with one where a file can be in two directories at the same time (no symlinks) - tags are the answer....
Ssshhh... they're gonna know the answer now! ;)
Hey - if they read dev.to - that goes a long way too... :)
Hard links?
A file in more than one location at once..? ZFS. ;)
Nice article here on SO from 2010:
stackoverflow.com/questions/326303...
that has links to a couple of experimental attempts for Linux and Windows, indeed rumour has it that Microsoft /almost/ shipped theirs with Vista :)
Whoa, it initially didn't occur to me that someone might make an entire FS out of this. That's interesting.
I actually like this implementation linked in there:
github.com/oniony/TMSU
A nice thing about tags is that they seem fairly fluid and casual in nature. As opposed to hierarchy and folder structure, which makes adjustments seem like a higher burden.
I too, have dreamed of such a system! There's loads of metadata that'd I'd love for files to have to and to be searched and organized over. WinFS would have been so lovely...
I am biased from Rails, but I think separating hierarchy based on architectural layers makes the most sense. Your first example seems confusing because you have verb (/controller) and noun/thing/object (/order) directories on the same level.
I am an avid user of exuberant CTags. I think here are bindings for other editors as well. Sublime: github.com/SublimeText/CTags
The first picture lists all tags “present” in the example project, it wasn’t meant to depict a useful layout. I should’ve made that clearer.
As for separating by layers vs. other ways, I think there are at least some good arguments for other styles e.g. packaging by feature or by “component” (in Simon Browns understanding). Also, I believe that one can successfully mix these styles once a codebase grows to a certain size.