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

21–30 of 47 posts

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

#21

Post by Sacho »

samatman wrote: post #16

Or, alternately, lay your code out like you'd lay out your workshop. In our houses we tend to use the same things in the same ways each day. There's just the one razor, keep it next to the shaving cream. In a workshop, we need to cooperate with other people, and even for ourselves, it's important to be able to find a tool when we need it. All the X-acto blades go in the same drawer, next to the drill bits. Which one…

What if the workshop grows into a factory? Then you have people walking into the gigantic tool closet, overwhelmed by all the tools they'll never use when they just want to find their wrench. I don't think metaphors really help here and it's mostly a matter of consistency and tooling. Instead of having to guess who uses a function or where it originates from, my editor gives me "go to definition" and "find all references". I also have "go to symbol", which allows me to search for classes or functions instead of having to browse the folder structure manually. I think it's best to optimize for the advanced tools we have to inspect a codebase instead of manual browsing and aesthetics.

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

#22

Post by [deleted] »

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…

[deleted]

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

#23

Post by w_t_payne »

How we store our documents; how we structure our work: This is a constant background channel of communication to the entire team, working tirelessly every moment of every day. It strongly influences how we think about our work, and is one of the best ways we have of influencing the engineering culture of our organisation.

Melvin Conway: "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

The way that we organise our filing system is nothing less than the (asynchronous) communications structure of the organisation, and needs to be architected with the same care and attention to detail.

By the same token, no single scheme will fit all organisations, and each team should seek to find a way of structuring their work that plays to their strengths and gives them a unique competitive advantage.

Here are my thoughts from over the years:

https://softwareengineering.stackexchange.com/questions/1458... https://softwareengineering.stackexchange.com/questions/8189... https://github.com/wtpayne/hiai/tree/master/a3_src

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

#24

Post by jwdunne »

cjcenizal wrote: post #4

I'm a fan of grouping by cohesion for the reasons the author lays out, but like any principle you need to understand how and why you're applying it. The author suggests grouping reducers, actions, and components by functional cohesion in a React/Redux app, but the point of grouping by layer in this case is to uncouple the layers in your app (UI vs. store vs. actions). In this situation, those layers represent the fun…

We're beginning to learn and refactor towards this approach.

We've already layered the app between state and UI. UI components are grouped by features. We've not done this with state but it makes sense to. But we can't see a benefit to merging state and UI layers. There are multiple UI features that make use of a set of actions and selectors.

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

#25

Post by samatman »

Sacho wrote: post #21
samatman wrote: post #16

Or, alternately, lay your code out like you'd lay out your workshop. In our houses we tend to use the same things in the same ways each day. There's just the one razor, keep it next to the shaving cream. In a workshop, we need to cooperate with other people, and even for ourselves, it's important to be able to find a tool when we need it. All the X-acto blades go in the same drawer, next to the drill bits. Which one…

What if the workshop grows into a factory? Then you have people walking into the gigantic tool closet, overwhelmed by all the tools they'll never use when they just want to find their wrench. I don't think metaphors really help here and it's mostly a matter of consistency and tooling . Instead of having to guess who uses a function or where it originates from, my editor gives me "go to definition" and "find all refer…

The article was basically "what if struct of arrays instead of array of structs?"

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

#26

Post by bigblind »

jdpigeon wrote: post #2

This sounds really good on the face of it but something in me is suspicious that this approach won't lead to even worse confusion in a real project. Maybe I've just been working in a certain way for too long and have gotten stuck in my ways..

It works well in the projects I've worked on, but I'd love to hear specific cases where it breaks down for you, since I've never worked in code bases developed by a large team.

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

#27

Post by bigblind »

bryanrasmussen wrote: post #15

well you might put your knives in the kitchen, but then you also need to have knives in the crafts area, or in the toolshed. so if you lay out your code like you'd lay out your house your code will not be very DRY.

There are cross-cutting (unintended knife pun) concerns, and I Usually do give them their own directory.

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

#28

Post by bigblind »

edem wrote: post #19

This article is horrible to read on mobile. It has a forced size which is bigger than what fits on a 5 inch display and I can't resize it.

I'm sorry, I was working on the mobile-friendliness of my site last night before I went to bed, but decided to prioritise sleep over pushing out the change. I wasn't expecting this post to get posted here, and now I'm kind o frustrated that so many people had a sub-par experience with my site. I'm pushing out an improved layout ASAP.

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

#29

Post by bigblind »

regularfry wrote: post #11
fmatty wrote: post #6

I love this concept when you are dealing with a blog that has posts and comments, or a todo app. However..in my experiences thus far, this type of cohesion becomes increasingly complex and open to individual interpretation when you are dealing with more complex business domains. Say for example, several different types of customers engaging in several different types of transactions that have just enough differences…

In this situation the best thing to do might be to make a choice, go with it for a while, and see how well the subsequent changes cluster. If all the changes in patches implementing features tend to be in the same place, you got it right. If not, time to reshuffle. Making a code layout like this is effectively making a prediction about what future changes are likely to entail. Predictions can be wrong, so we want to…

I think that if changes are small, you can just update the structure in small increments as needed, just like you'd do any other refactoring.
Post reply on HN