Afaik phoenix opted out of the convention to prevent having tons of .Controller and .View modules.
LostKobrakai
2
peerreynders
My perspective on MyAppWeb.Controllers.Page:
Pagemodule- in the
MyAppWeb.Controllers“namespace” - therefore I expect
Pageto be a single controller - one among many in theMyAppWeb.Controllers“namespace”.
So the pluralization isn’t in the service of a good folder or module name but to create the sense of a namespace.
Now when it comes to the wisdom of having separate MyAppWeb.Controllers and MyAppWeb.Views namespaces given how tightly coupled controllers and views tend to be - that is a separate discussion (as I recall there are technical reasons for this as views require very different build processing from controllers - I’ve never been fond of the Rails convention of collecting “like things” under the same namespace (when we are not dealing with a (standard) library); I’m more of a put things that work as a cohesive whole under the same namespace sort of guy).
7
AstonJ
Ah that makes total sense. (For some reason I was thinking about automatic pluralisation (and conventions) that happen in frameworks like Rails (and not in Phoenix) of modules/schemas etc, rather than the generated structure on creation.)
I quite like that too!
Thinking about it, and I remember it was discussed somewhere but not sure where now - does anyone know why in Phoenix we dropped the web folder for MyAppWeb? I think Web.Controller.Page or Web.Controllers.Page is much cleaner.
1
OvermindDL1
I’ve noticed that myself, I’ve accidentally let slip a camel-cased filename in my folders… ^.^;
A ‘direct’ mapping would be putting it in lib/MyApp/Sensors/Supervisor.ex though?
Lol, so git without the filename part of the tag? ^.^
My dream has always been a database of code personally. Everything properly linked together, denormalized, etc… Mmmm…
As something similar, OCaml uses lower-case-initial-character filenames but Modeles always start with an upper case characters. I’ve always found that odd too. In C++ I have the filenames match the case of the namespace/static-class that are defined in.
I prefer the MyAppWeb.Controllers.Page style too, but that is harder to macro’ize automatic linking with Views and all as the ‘Controllers’ part could be arbitrarily higher from the current controller name if you use a hierarchy and such things, so for macro’ing reasons having it be appended seems ‘safer’.
2
boydm
Creator of Scenic
Ah. That makes sense. I’m not trying to macro-ize anything, so am going to try to stick with the more readable name.
2
wojtekmach
Hex Core Team
I believe the reason that Phoenix has PostController instead of Controllers.Post is that it’s pretty common to alias modules and it wouldn’t be possible to have in the same module the following:
# contrived:
alias Controllers.Post
alias Views.Post
alias Blog.Post
A good example where not sticking to 1-1 mapping between file and module is in Elixir itself: elixir/lib/elixir/lib/calendar at main · elixir-lang/elixir · GitHub, we have lib/calendar/date.ex defines Date, instead of Calendar.Date. It’s very convenient to keep these files together.
What I personally try to do is to stick to 1-1 mapping in the vast majority of cases but sometimes, very rarely, diverge from it when it has some benefits.
20
dimitarvp
@joeerl I quite like Java’s way of enforcing the same file name as the class name (when the class is public anyway), and forcing one class per file:
Go has conventions that the compiler enforces:
I don’t quite like the more liberal approach of Elixir because I’ve seen people put 4 modules in a single file and the name of the file does not even reflect the purpose of the bunch of modules. Granted that’s not often the case but IMO the tooling should not give you the ability to shoot yourself in the foot.
Conventions are only good for as long as the inhabitants of the ecosystem are willing to comply with them.
I understand some of the counter-arguments though – like convenient aliasing and naming consistency for the sake of macro automation / code generation.
I would absolutely do this. It gets tiring chasing files in directories even with an IDE. When a project grows beyond a certain point however, a single directory becomes unsustainable (I’d say if you go beyond 40-50 files; the whole thing has to be human-friendly after all). But right now I think that having separate directories for 1-2 modules (usually the root of your app – lib/my_app/my_app.ex) is taking it too far and is unnecessary. Same for the separate directory for 1-2 supervisors. Configuration and tests do make a lot of sense in where they are now, but nothing much else really.
I’d like to see more conventions inside the lib/ or lib/my_app directory contents, like supervisors/ or background_workers/. And a flatter directory structure overall.
I can’t argue a directory hierarchy is very useful for Phoenix projects though. Or umbrella projects where you can have an app for Phoenix site, GraphQL gateway, REST gateway etc.
EDIT:
In a recent project I had these two files in lib/: my_app.ex and cli.ex, where the latter file contained a module named MyApp.CLI. Still not sure if the CLI file should be named my_app.cli.ex or be forced to my_app/cli.ex. I lean toward the former because I think Elixir projects have too many directories with too few files in them.
1
axelson
Scenic Core Team
If you want to use credo to enforce the module name there’s a PR up for that feature: https://github.com/rrrene/credo/pull/587
4
joeerl
Creator of Erlang - Fondly Remembered
Just a followup - over the years I have tried many different ways of organising files - non of them are good.
What I currently do (or am tending towards) is the following:
a) All modules that I think I might reuse are put in the same directory (called Dropbox/elib) with hopefully meaningful module names.
The advantage of this is I can grep for things in this directory and easily find things.
The Dropbox bit means my files are synced across all the machines I use - so for shared code there is one version (the latest) with a unique name on all machines.
It’s not even in GIT - I don’t want all old versions of the code just the latest and I’ll change the name if I make significant changes to the code - (and I’m not collaborating with anybody here - for collaborative code I do use GIT - but for private projects I don’t care about branches and saving old versions - just the latest is fine)
(I should add that I’m old-school - I learned to program before revision control systems where invented - so we developed strategies based on file naming that were useful - these strategies are a lot simpler than things like GIT and are fine for personal projects - but not for big collaborative projects)
b) All projects go into a sub-directory of Dropbox/experiments with a meaningful name
c) Inside a project directory (say Dropbox/experiments/transluder) local modules are just stored anywhere - but modules using the shared code in lib I just add as symbolic links.
This has a few advantages - my ls command colors symbolic links so I can see they are shared. The editor always edits the master version (in lib) - all experiments using the shared library get to see the same version of the code.
What I actually hate is having multiple versions of a file with the same name in different directories. These files endup with different sizes and modification dates. Some go back 30 years and all are slightly different.
I also hate the idea that files with the same name (in different directories) can have different contents. It’s ok for a file with a unique name in a single directory to have time varying content - I’m usually only interested in the latest version.
Before GIT (and friends) I used to name files with names like lib_this_vsn1 lib_this_vsn2
etc. bumping the version when appropriate. This was great - all the old versions were frozen and we knew that the greatest vsn could change without warning. This was how erlang was developed 
- there was no GIT @rvirding and I worked on a module until we got fed uo and then mailed the latest version to each other.
GIT etc hides this so we just say lib_this - the problem here is this fails the “telephone test” - ie if we were to tell somebody "code code is in the file XYZ’ two people could view the file at the same time (both see it is called XYZ) but they are looking at a different version of the code and are not aware of this fact. This has happened to me so many times since files get them selves detached from their revision control systems (for example by send in mails) and is large source of errors.
Actually there this is a symptom of a much deeper problem - but there is not room here to explain this (short version - the problem lies in editors, they do not record where the data in the file came from in the first place)
6
OvermindDL1
Careful with that, dropbox has been known to corrupt git repo’s like that! I’d recommend using KeyBase’s git storage. It also has distributed file storage like dropbox if you need it, but it has a specialized git area that keeps consistency and safety unlike the distributed file storage style that both keybase and dropbox use.
Ah you just keep files, well still be careful about offline synching potentially changing files versions in unexpected ways too, use git instead (github, gitlab, whatever)! ^.^
+1 I have so many slightly edited versions of so many files from programming 20-30 years ago… >.>
And I even used the CVS era (I still have my old SVN server running…).
Precisely, that is why you say a file at commit <hash> (or even just joe/master or so), or just a link to it in your git server now.
But yeah, this is inherently disconnected so will get out of sync, everything should stay in the VCS.
Hmm…
Many editors now can show precisely when a line was added based on git, the commit, the message of the commit, get details about the branch, commit, server, etc… I can literally just slide a scrollbar to go backward and forward in history.
2