I made a tool for this some time ago. It detects when programs write to your home directory outside the XDG spec and logs the file and the location of the binary that wrote it to an SQLite file.

We could probably stand to have some organisation standards in repo roots, but I tend to agree that dotfiles aren’t the way to go there. The project root is similar to ~/.config and the like: When you’re there you should not be subjected to further hidden levels. Those config files are a significant part of the project.

State files however, like all the stuff in .git, lockfiles and the like are generally¹ fine to hide away. Those are side effects of running other tools, not ordinary editable configuration. Same goes for cache—and both cache and runtime files should likely go in the ordinary XDG dirs rather than be something every project has to set up a gitignore for.

If anything I’m more frustrated with the C projects that just plop every source file in the root directory.

¹ Just don’t make it too easy to sneak unexpected crap in there. We don’t need to make the next Jia Tan’s job easier.

I don’t mind this problem so much but what does drive me crazy with Docker images is that oftentimes all those crazy top level files are included in the Docker image (for no reason). I’ve even seen .git/ in Docker images.

I prefer the Dockerfile itself to be at the top level but it feels like no one wants to keep their layers clean. But writing Dockerfile syntax is an art form in itself that I probably shouldn’t continue rambling about here.

Many of them don’t even allow it to be a hidden file—they just require a fully unhidden “tool.yml” file sitting right there in the root of your project.

I love this. I hate when tools only allow hidden config files. I want to know where the config is—my teammates should be aware of where the config is. I don’t want to be tricked into thinking there isn’t a config file in a directory.

I actually have alias ls='ls -A' in my bashrc so I see everything.

Check my dotfiles https://github.com/Samueru-sama/dotfiles

0 hidden files, everything is in ~/Local.

Recently added this hack for ssh: https://github.com/Samueru-sama/dotfiles/commit/7e1f8bd3173da563731aea6db9efbf26a2b23e72

For tool configs? I’m not really sure I follow. All my source code for the project goes in src/ or some other subdirectory, and the project root is a bunch of configs, a source directory, maybe some scripts, etc. It’s never really bothered me.

What has bothered me is __pycache__ directories. Whoever decided to litter those in every source directory all over the place… let’s just say I hope they learned to never do that again. I deal with enough trying to get Python to work at all (with the absolute hell it is to get imports working correctly, the random, but admittedly mostly documented, BS gotchas littered all over the standard library, packages with poor docs, no types, and every function worth calling taking **kwargs, etc). Seeing my code littered with these directories isn’t something I really want to deal with as well.

A standard for build output might make sense to me. Maybe just throw cache stuff in .cache and build output to .build (with intermediate artifacts in there as well potentially). For configs, I wouldn’t really complain about it all going in .config, but it also doesn’t matter much to me, and sometimes you end up having nested configs anyway in nested project dirs (thinking of eslint configs, gitignores, etc).

yeah, I’ve also been noticing this in the past months. The number of dotfiles in project roots is an ever growing number, to the point where we have literally dozens of files and directories and only a handful that actually mean anything to the project. It’s pure clutter.

Yep, the repository root. Where everyone starts to read your code, so you put your README there and the docs-folder and the entrypoint to your source tree, oh and also all this random guff that no sane reader would ever be interested in.

I still remember how I tried to read larger repositories for the first time and this was genuinely a hurdle, because I figured these files must be highly relevant for understanding the code.

My attempt at combating that has been to move as much of the code structure to the top as possible, so that someone new will have a much higher chance of clicking on something relevant. But yeah, downside is that your code structure isn’t as separated from the guff anymore…