3 ms·

A hierarchical structure is simply not sufficient to express the various overlapping relations that exist in code. Having to apply a single tree structure is al

A hierarchical structure is simply not sufficient to express the various overlapping relations that exist in code. Having to apply a single tree structure is always going to be painful somewhere, even with an optimal solution. You're likely to get more payoff from reducing dependence on file system structure than from optimising said structure. > But since the file is not located near the change, you need to search through the entire code base to see where the changed function is called in order to update the calls. You can't really rely on all change being locally restricted, so you have to check the wider code base, anyway. Search through the entire code base should be easy, simple, and fast. If it isn't, that's a bigger problem than the directory structure of the project not being ideal.

w_t_payne 8y ago
I agree with your initial point: A single explicit hierarchical structure will never please everyone all of the time: There are too many implicit relations that could (and arguably should) be captured. It might be tempting to try to maintain multiple directory structures, making use of hard or soft links into the code base, but this sounds like it might be fragile, not to mention hard work to maintain. I am sure others have also tried to abandon hierarchical file systems altogether, placing the design into a database instead. This also seems like a lot of work, although I can see the attraction. My solution is to embrace the conflict and take an opinionated approach to the hierarchy -- one that enhances and supports the development process -- but to supplement that with generated HTML documentation with multiple different hyperlink-based navigation schemes. At some point, I also plan to integrate a javascript text editor into these HTML reports, at which point the whole contraption will have transmogrified into a sort of Kentucky IDE.
- JadeNB 8y ago
  > It might be tempting to try to maintain multiple directory structures, making use of hard or soft links into the code base, but this sounds like it might be fragile, not to mention hard work to maintain. There are a lot of projects organised around automating this maintenance—though they tend to pop in and out of existence, so I'd agree we're not at the state of having a reliable solution that'll be around next year, or next month. TagFS (https://github.com/marook/tagfs https://github.com/marook/tagfs) is the system with which I've been familiar most recently, but it appears to have been dormant for four years.

w_t_payne 8y ago

I agree with your initial point: A single explicit hierarchical structure will never please everyone all of the time: There are too many implicit relations that could (and arguably should) be captured. It might be tempting to try to maintain multiple directory structures, making use of hard or soft links into the code base, but this sounds like it might be fragile, not to mention hard work to maintain. I am sure others have also tried to abandon hierarchical file systems altogether, placing the design into a database instead. This also seems like a lot of work, although I can see the attraction. My solution is to embrace the conflict and take an opinionated approach to the hierarchy -- one that enhances and supports the development process -- but to supplement that with generated HTML documentation with multiple different hyperlink-based navigation schemes. At some point, I also plan to integrate a javascript text editor into these HTML reports, at which point the whole contraption will have transmogrified into a sort of Kentucky IDE.

JadeNB 8y ago
> It might be tempting to try to maintain multiple directory structures, making use of hard or soft links into the code base, but this sounds like it might be fragile, not to mention hard work to maintain. There are a lot of projects organised around automating this maintenance—though they tend to pop in and out of existence, so I'd agree we're not at the state of having a reliable solution that'll be around next year, or next month. TagFS (https://github.com/marook/tagfs https://github.com/marook/tagfs) is the system with which I've been familiar most recently, but it appears to have been dormant for four years.