I’m defining N types and let’s say there are 5-15 functions for each types. How would you structure your code?
- Each file contains a single type and related definitions
- One file contains all types, and a separate file for defining functions for each type
- Something else…?
This really depends on how large N is, and how long/complex the functions are.
I usually try to keep things in one file until that gets too large, then split.
What I usually do is have a file where all related types are defined and then I have a separate file where I define the operator algebras on those types. Both of those files are included from the main module. This separates the type definitions and their algebra. Utility methods are usually included with the type definitions. The algebra code can grow quite large due to the combinatorial possibilities of 10-15 types, so it needs to be kept separately to grow.
I try to keep concepts in their own files, so one abstract type and all its concrete types and all their methods in one file. The only real reason I do this is because it’s easier for me to navigate from one concept to the other in Vim. I just move between (Vim) buffers to get to where I want. If everything was in the same file I’d need to search the file to get to where I want. The biggest disadvantage I guess is that when you open a
src directory it might “look” like this project is overly complex, but some of my files contain just 5 lines…
I would say it is definitely oversplitting.
Also, I think it is better to adapt your editor to the way you prefer to write Julia code than the other way round.
Meh… I bet you’re right, but this seems to work. I mean, is there any real dis/advantage to “over/under splitting”?
I totally agree. I’m getting a new computer soon and I’ll be ricing that to “completion”…
The compiler does not care, of course, so if that’s what you mean by “real”, there is no downside — you can put every single function in its own file (there is actually a pretty widely used scientific programming language that does this ).
But humans may find it easier to look at meaningful units of code. Think about the readers of the code, and try to make it easy for them to follow what you did. It is difficult to be more concrete than this; the problem is not unlike organizing chapters in a book, or planning the layout of a garden, or designing a building.
I normally mimic
object oriented design, and each file is a module with a type and all the methods applies to it. As a result, I can use
Module.method(type, parameters). I can easily list all the methods applying to that type in editor. The
methodswith function is nice, but could not be used in editor to list all the available methods corresponding to that type.
I really need to understand better how to use modules separately from packages…
Depends, but usually (2). The various types in one file and the implementation of the API in another.
That seems natural for some people. What do you do when you have functions that take multiple types then? Do you create a separate file for these “interaction functions”?
the types are ordered, the later type can use dispatch to interact with previous type. This is not a good design since the methods with kind of scatters to other type files, but these kinds of functions are only a few in my application.