Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lay Out Your Code Like You'd Lay Out Your House

frederikcreemers.be

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Lay Out Your Code Like You'd Lay Out Your House

#41

Post by Firadeoclus »

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.

Re: Lay Out Your Code Like You'd Lay Out Your House

#42

Post by w_t_payne »

Firadeoclus wrote: post #41

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 t…

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.

Re: Lay Out Your Code Like You'd Lay Out Your House

#43

Post by andreareina »

chrismorgan wrote: post #14

The main argument I’ve come across against this is that text editors commonly put great weight on file names—opening by file name, showing the file name without its containing directory structure or with it harshly abridged (e.g. /h/c/B/p/controllers.py). It would be nice for this to be addressed better in editors, but it is a bit of a tricky matter to handle across varying projects. Of course, as presented, having l…

I like how emacs does it: when there's one file open with a particular name, show just the name; when there's more than one, there's a legend with as much of the path as needed to disambiguate.

* unique filename: filename.ext

* common filename, different directories: filename.ext

* common filename and immediate parent directory name: filename.ext

* etc

Re: Lay Out Your Code Like You'd Lay Out Your House

#44

Post by captainbland »

slfnflctd wrote: post #39
captainbland wrote: post #38

This is pretty similar to how I like to structure my code - basically by feature rather than by type. I find there's a lot less mental overhead to working this way, but it can bite you if you end up with a lot of code that is shared between features. Plus what a 'feature' is can be more subjective than what a type of class is and some teams might struggle because of strong, contrasting opinions on this. That said, wh…

When you say "file name conventions" at the end there, are you simply thinking of the importance of being consistent in their usage, or is this a reference to something more specific?

Consistent in their usage, of course - it helps if, for instance, your tests have something referring to the fact that they're a test in the name. It's common for them to have 'UT' on the end so that when you do a search for "MyFancySomethingServiceUT" you can be reasonably confident it'll find your test.

Re: Lay Out Your Code Like You'd Lay Out Your House

#46

Post by JadeNB »

w_t_payne wrote: post #42
Firadeoclus wrote: post #41

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 t…

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 othe…

> 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) is the system with which I've been familiar most recently, but it appears to have been dormant for four years.

Re: Lay Out Your Code Like You'd Lay Out Your House

#47

Post by fouc »

Nerves that fire together, wire together. Input that happen together end up mapped to nerves close to each other, so the neural maps in the brain end up in the same order as the parts of our body. Thumb and index finger input end up next to each other in the brain neural map.

We could setup our code to self-organize under similar principles perhaps.

Post reply on HN