4 ms·

The concept of linting repo structure is an excellent one. I cannot even get started in projects without a sane repo layout. Source files scattered everywhere

The concept of linting repo structure is an excellent one. I cannot even get started in projects without a sane repo layout. Source files scattered everywhere unrelated to each other, utils junk-drawers with dozens of files, multiple top-level source directories without explicit rationale, tests and source totally disjoint, hacks to modify build and run paths, implicit dependencies between directories, awful convoluted build-system configuration to match all of these idiosyncrasies, and impossible or very difficult editor/ide integration as a result. Even rails-eque apps (which come with a reasonable structure) get really messy really quickly if somebody doesn't have the diligence to stay on top of it. I want there to be a {sane, polyglot, large-ish-scale} project layout convention that plays well with {intuition/discoverability, build-systems, editors, project size}, but it seems there's an inherent tension between these. Maven tried. Kinda. I wonder if there's a fundamental problem we aren't solving somewhere.

DelightOne 6y ago
In maven I don't like the test-separation from the code itself because its much simpler to find and update them this way.
- ryanianian 6y ago
  There's a lot to not like about maven. I think that separation was motivated by java's classpath rather than making a 'good'/dev-friendly convention. After 10 years in maven-land, I changed a recent project to put `foo.ts` and `foo.test.ts` in the same directory and its wonderful, but it confuses some build-systems and makes certain kinds of test-helpers harder to write.
  - shepherdjerred 6y ago
    Maven is my favorite thing about Java...
- advaita 6y ago
  Anecdotally, I like that separation because in absence of it working with any large-ish project (which most real life projects are), it'd get super hard for my brain to pick out tests even if they all had certain prefix/nomenclature. Caveat: I use IntelliJ and I just jump to tests using CMD+SHIFT+T shortcut so not necessarily a generic example.
hinkley 6y ago
I'm a little disappointed we haven't collectively stolen 'mis-en-place' from professional chefs. Working in chaos is just masochism. There will be enough chaos you can't control, don't add accidental chaos to the system.
- jressey 6y ago
  Ex-cook here, more than 10 years. Learn about mise-en-place and implement it in your work. It will be painful as hell but you will begin working far more quickly and accurately than your coworkers and it will likely end up with you leading. I see so many similarities in the jobs. Great mise-en-place makes a great cook just the same as a great dev. Remember though, even the best cooks have to chop garlic during service occasionally.
- SirLuxuryYacht 6y ago
  I hear you. It's a really good metaphor, but it seems to get strained when your 'mis' is more than 20 ingredients.
  - ashtonkem 6y ago
    Also, French is much more the lingua Franca of cooking than it is software engineering.
  - filleduchaos 6y ago
    Your "putting" is more than 20 ingredients? (I do get your meaning, I just found your phrasing a bit funny.)
  - hinkley 6y ago
    I learned mis-en-place from a bike mechanic, and 20 'ingredients' isn't even table stakes for a mechanic (unless you count each wrench or socket set as 1 tool, and then we're close). There were only two 'adults' in that shop - the manager, and Bob, the senior mechanic, and I'm pretty sure both of them were maybe 28. The rest of us were college age. He was constantly irritated that we couldn't seem to keep our shit organized. Most of the time this was some muttering or making little jokes at our expense. Until you wanted to borrow one of his tools because you couldn't find yours, then you got an earful. I was pretty sure I didn't like Bob at first, but now I'm not so sure.
smcameron 6y ago
On the flip side, reorganizing a codebase totally fucks the git history.
- el_dev_hell 6y ago
  If you do it all in one swoop it's not too bad. The difficult part is managing everyone's "perfect structure".
- irishcoffee 6y ago
  hg move $thing. I’m bummed git “won”
  - filleduchaos 6y ago
    `git mv` also exists.
  - jrockway 6y ago
    I think you can find edge cases in either tool where the data exists to make something work, but the data model doesn't allow it. Consider a file like "package foobar; func DoFoo() { ... }; func DoBar() { ... }". You then refactor that to two packages, "package foo; func Do() { ... }" "package bar; func Do() { ... }". The body of foobar.DoFoo is identical to foo.Do, but no version control system I've ever used will move the history of that function body to the new location. I guess what I'm saying that tracking renames as a first-class object is nice, but it still doesn't represent many types of refactorings. To smugly declare perfection, a version control system should probably have that feature, because it is a relatively common refactoring.
    - irishcoffee 6y ago
      Of course a tool that tracks the history of file changes doesn’t do your example. That’s not an edge case, it’s a flawed argument contrived to try and make a point, albeit poorly.
- vimax 6y ago
  Just make sure to use 'git mv' for all your files so the history can be tracked. 'git log myfile' will only show the history for that file, but 'git blame' will follow the line changes across file moves. That aside, there are some many productivity and tooling gains around organizing your project properly, that it is worth history discontinuities. Also, I've found that the worse the project organization is, the less likely the team is to separate out different fileset changes into different commits to keep a useful history, or make the use of the git history at all outside of looking at a few recent commits or or sometimes looking at the last release. I've heard this as very circular arguments. Can't re-org because we loose history. Can't maintain good history because the project is too disorganized.
thundergolfer 6y ago
Bazel’s ‘visibility’ attribute for build targets can be the foundation of a repo structure linting solution. If maintained properly, visibility settings can stop a bad code structure move in its tracks.
amelius 6y ago
Perhaps we should hard-code a rule (make it a cross-language industry standard) that says that the dependencies of a module should always be listed with the module (in a fixed format) and the build system doesn't allow the use of anything else (as a verification step). That way, we could have a tool that always correctly shows the dependencies between modules.
- majewsky 6y ago
  While we're at it, build semantic versioning into the package repository. For instance, if you push a version 1.1.3 that has a different API than version 1.1.2, the repository should just outright deny the push and require you to publish this as version 1.2.0. It's a little annoying on the part of the library author, but would make all consumers of the library much more confident in upgrading.

DelightOne 6y ago

In maven I don't like the test-separation from the code itself because its much simpler to find and update them this way.

ryanianian 6y ago
There's a lot to not like about maven. I think that separation was motivated by java's classpath rather than making a 'good'/dev-friendly convention. After 10 years in maven-land, I changed a recent project to put `foo.ts` and `foo.test.ts` in the same directory and its wonderful, but it confuses some build-systems and makes certain kinds of test-helpers harder to write.
- shepherdjerred 6y ago
  Maven is my favorite thing about Java...
advaita 6y ago
Anecdotally, I like that separation because in absence of it working with any large-ish project (which most real life projects are), it'd get super hard for my brain to pick out tests even if they all had certain prefix/nomenclature. Caveat: I use IntelliJ and I just jump to tests using CMD+SHIFT+T shortcut so not necessarily a generic example.

hinkley 6y ago

I'm a little disappointed we haven't collectively stolen 'mis-en-place' from professional chefs. Working in chaos is just masochism. There will be enough chaos you can't control, don't add accidental chaos to the system.

jressey 6y ago
Ex-cook here, more than 10 years. Learn about mise-en-place and implement it in your work. It will be painful as hell but you will begin working far more quickly and accurately than your coworkers and it will likely end up with you leading. I see so many similarities in the jobs. Great mise-en-place makes a great cook just the same as a great dev. Remember though, even the best cooks have to chop garlic during service occasionally.
SirLuxuryYacht 6y ago
I hear you. It's a really good metaphor, but it seems to get strained when your 'mis' is more than 20 ingredients.
- ashtonkem 6y ago
  Also, French is much more the lingua Franca of cooking than it is software engineering.
- filleduchaos 6y ago
  Your "putting" is more than 20 ingredients? (I do get your meaning, I just found your phrasing a bit funny.)
- hinkley 6y ago
  I learned mis-en-place from a bike mechanic, and 20 'ingredients' isn't even table stakes for a mechanic (unless you count each wrench or socket set as 1 tool, and then we're close). There were only two 'adults' in that shop - the manager, and Bob, the senior mechanic, and I'm pretty sure both of them were maybe 28. The rest of us were college age. He was constantly irritated that we couldn't seem to keep our shit organized. Most of the time this was some muttering or making little jokes at our expense. Until you wanted to borrow one of his tools because you couldn't find yours, then you got an earful. I was pretty sure I didn't like Bob at first, but now I'm not so sure.

smcameron 6y ago

On the flip side, reorganizing a codebase totally fucks the git history.

el_dev_hell 6y ago
If you do it all in one swoop it's not too bad. The difficult part is managing everyone's "perfect structure".
irishcoffee 6y ago
hg move $thing. I’m bummed git “won”
- filleduchaos 6y ago
  `git mv` also exists.
- jrockway 6y ago
  I think you can find edge cases in either tool where the data exists to make something work, but the data model doesn't allow it. Consider a file like "package foobar; func DoFoo() { ... }; func DoBar() { ... }". You then refactor that to two packages, "package foo; func Do() { ... }" "package bar; func Do() { ... }". The body of foobar.DoFoo is identical to foo.Do, but no version control system I've ever used will move the history of that function body to the new location. I guess what I'm saying that tracking renames as a first-class object is nice, but it still doesn't represent many types of refactorings. To smugly declare perfection, a version control system should probably have that feature, because it is a relatively common refactoring.
  - irishcoffee 6y ago
    Of course a tool that tracks the history of file changes doesn’t do your example. That’s not an edge case, it’s a flawed argument contrived to try and make a point, albeit poorly.
vimax 6y ago
Just make sure to use 'git mv' for all your files so the history can be tracked. 'git log myfile' will only show the history for that file, but 'git blame' will follow the line changes across file moves. That aside, there are some many productivity and tooling gains around organizing your project properly, that it is worth history discontinuities. Also, I've found that the worse the project organization is, the less likely the team is to separate out different fileset changes into different commits to keep a useful history, or make the use of the git history at all outside of looking at a few recent commits or or sometimes looking at the last release. I've heard this as very circular arguments. Can't re-org because we loose history. Can't maintain good history because the project is too disorganized.

thundergolfer 6y ago

Bazel’s ‘visibility’ attribute for build targets can be the foundation of a repo structure linting solution. If maintained properly, visibility settings can stop a bad code structure move in its tracks.

amelius 6y ago

Perhaps we should hard-code a rule (make it a cross-language industry standard) that says that the dependencies of a module should always be listed with the module (in a fixed format) and the build system doesn't allow the use of anything else (as a verification step). That way, we could have a tool that always correctly shows the dependencies between modules.

majewsky 6y ago
While we're at it, build semantic versioning into the package repository. For instance, if you push a version 1.1.3 that has a different API than version 1.1.2, the repository should just outright deny the push and require you to publish this as version 1.2.0. It's a little annoying on the part of the library author, but would make all consumers of the library much more confident in upgrading.