Comment by ryanianian | Hacker News Reader

Comment by ryanianian | Hacker News Reader

Parent Full thread

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.

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.

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.

I hear you. It's a really good metaphor, but it seems to get strained when your 'mis' is more than 20 ingredients.

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.

Your "putting" is more than 20 ingredients?

(I do get your meaning, I just found your phrasing a bit funny.)

Also, French is much more the lingua Franca of cooking than it is software engineering.

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.

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.

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

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.

Maven is my favorite thing about Java...

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.

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

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.

Has behavior for `git mv` changed? Last time I investigated, the command was convenience to `git add` after a `mv` with a single command. Git doesn't actually explicitly track renames, it leverages some sort of auto-detection based on file content similarity.

Still good to use the command, just keep in mind git isn't really treating it any different than a normal `mv` followed by `git add`.

https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_no...

This might not be the forum for it, but I have a question about this - I thought git was supposed to be pretty smart about detecting renames, but in my experience (on Windows) it never does, and I always have to use `git mv`. What's the deal with this?

Even if rename detection is enabled, git will only try to identify renames if it wouldn't take too much time (since IIRC it's a O(#files^2) operation).

Thus, there's a config "diff.renameLimit" and "merge.renameLimit" that tells git to only detect renames if less than N files are affected.

I have personally been burned by this before, and there usually is a default value set in most git clients.

See also some discussion at https://stackoverflow.com/a/7831027/1237375 .

It does work, check what happens after you git add it all, not before.

'git log --follow' should try and log following back through the rename. It can be a bit slow with big repositories though.

If you do it all in one swoop it's not too bad. The difficult part is managing everyone's "perfect structure".

hg move $thing. I’m bummed git “won”

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.

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.

`git mv` also exists.

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.

Reply on news.ycombinator.com