Module naming conventions

That is indeed pure insanity. FWIW, I’ve seen lots of projects that way on Windows–it seemed to be common practice. And historically there was a good reason for it. For a very long time, include paths in the predecessors of Visual Studio were comma-delimited in a single text field, they were not recursive, and the text field was limited to 255 characters. (Yes, that was INCREDIBLY stupid, but it was what it was.)

My point was that it doesn’t have to be that way. I’ve worked on projects where it is not done that way, everything is just checked into a single folder. Its pure insanity.

Yes I do mean “something like that” - It would be perfectly possible to record meta-data associated with each cut-and-paste information and save all of this,

Many word processors have a track-changes operation, but usually you cannot unroll all previous edits - only the latest - and if you pasted data from some other source you cannot dig down into the other source.

The ability to dig down into text to see where it came from is one of the ideas in Xanadu by Ted Nelson. Ted coined the word “hypertext” and had some great ideas about what was wrong with files.

Some of the ideas of tracking data sources can be found in

Just needs to be implemented

It’s perfectly possible, pretty easy even, to keep the on-disk file structure the same as Xcode’s groups. (I would go insane if I didn’t.)

Doesn’t the history show that? It shows branches and merges and comments and all?

Oh you mean something like that! I think that kind of thing would require interface changes through-out everything and as such is untenable at this time.

I personally usually put a comment with the webpage or so of where something came from if I copy something. ^.^

After all, it’s not like the program can read your brain and know that you aren’t typing it from your phone screen or something.

Sure you can find when a line was added - but I want to know where the line came from

Suppose I browse to some web page - select some text and put it in the “cut” buffer
then I paste this text into a file that I’m editing - all the editor knows is that the
text came from the cut-and-paste buffer and NOT the web page that I cut-and-paste from.

After the event when I read (or somebody else reads) the text they might be left wondering “where the heck did this data come from” - I’d like to drill down and find out exactly where everything came from.

Editors just record keystrokes - but they don’t know or care or record where the data came from - so one of the most important questions “how the heck did the author of this text get the necessary information to write this text” is not answered.

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…

image474×175 13.6 KB

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.

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)

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

@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.