We need a better directory structure

[fj128]

Instead of vlad_scratch/ have scratch/vlad/ etc on the top level.

Put all solvers into a production/solver/ directory.

Because in my opinion we have enough people that having all these postfixed *_scratch/ directories on the top level is annoying, same for postfixed production/*_solver.py.

@Vlad-Shcherbina if you agree then it's actionable for you, make the correct directory structure when making the icfpc2019-tbd repository.

[Vlad-Shcherbina]

The original reasoning for flat scratches (besides the fact that you started it like this) was to make it easy to move modules between scratch and production (production had flat structure back then too) while preserving the meaning of the relative path '../'.

Nowadays its irrelevant. Production is hierarchical and paths should be relative to project_root() anyway. So there is no reason why scratch can't be hierarchical too.

No strong opinion on solvers, and it's problem specific anyway. If I wrote the first solver, I wouldn't put it in the solvers package, but if it turns out there are too many of them, no problem to move them later.

[Vlad-Shcherbina]

By the way, I like this post: https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33

In summary, it describes four ways to organize code into hierarchical units:

1. By component (good). Coupling, functional cohesion, all that stuff.
2. By toolbox (ok). The parts of a toolbox are often complementary implementations of the same interface. E.g., the collections package.
3. By layer (bad). E.g. HTML/js/server. The problem is that there are too many things that span across multiple layers.
4. By kind (shit). All classes, all exceptions, all services, all tests.

---

solvers package is either 2 (ok) or 4 (shit), depending on how you look at it.

[fj128]

The problem I wanted to address was that we accidentally settled on a named scheme that is very unfriendly to a person looking at files sorted by name. On the top level we have several useful directories literally interspersed with *_scratch stuff that nobody cares about. In production we actually ended up with 47 files including 8 solvers semi-randomly spread among them.

When we have too much stuff we need to organize it by categories for the sole purpose of not having to look at too much stuff at once and being able to find the stuff you need faster. Any organizing principle is better than having an unsorted bag of junk. Having a dedicated directory for solvers is good IMO because it's a natural, interesting, and sufficiently large category of files.

I'd be OK even with just a different naming convention like scratch_fj and solver_default, but I think that directories work even better (and don't conflict with non-solvers called solver_utils, solver_runner etc).

I don't want to make tests separate based on the same logic because the benefit of being able to quickly open both some module and the tests for it is just too great.