very newbie question here. Say I have a project in “Project” folder, with a couple of “.jl” files that are considered the main program(s). Now, I’d like to write some functions that will be called by the main program (perhaps all the main programs or only one). What’s my options?
1- create a new module “myModule” and put it into .julia/v0.5/myModule
2- Write the function directly into the main program
3- Create a new file “myFunction.jl” in “Project” folder and add “include(“myFunction.jl”)” at the beginning of the new program?
4 - ?
What’s the good way of doing it?
Right now, I know that option #1 might be the “best”, but I find it perhaps too much work for simple or little functions. I don’t like option #2, because I always thought that the main program was harder to read like that (though it might be more portable between colleagues… ?).
Option #3 is what I always did in Matlab.
Perhaps it’s a combination of these answer? I mean, I can begin by addind the functions to the main program and if the function grows or become more generic I should transfer it to a module when this time comes?
Other option? Sorry if it’s supposed to be easy, I’m not considered a developer with regards to developing code.
Even if you were told the perfect way to organize your functions (and you can find many books on the matter), you would find it hard to apply it in practice, and that would make you less productive. I would suggest that you utilize and even experiment with all the ways that you find natural at the time.
For example, it is natural to write a new function directly into the main program, where you have easy access to it, in order to review, edit and improve it. Just do so. But as time passes and your main program grows in size, you will find it natural to move some more-or-less crystallized functions out of it and into separate files, so as you can focus on the new functions. As the crystallized functions increase, you will notice (sometimes even by their names) that they can get naturally grouped into modules of a common theme. You will also notice that most functions in a module work on the same custom types, so you will find it natural to move the definition of those types in the same module. Continuing like that, you will find your code developing and yourself being a developer.
I see! Thanks for sharing your thoughts on the workflow. It makes sense. Perhaps I had a more rigid take on it and it’s probably better to go with a more natural flow as you described.
This will always depend on how big your project is. At first, sure, throw your first few functions directly into the module. Once the module is too big, start making files for related functions, and group them together. (Please don’t do the one function per file MATLAB thing, that was never a good idea)
If your project gets really big, then you make folders for related files, and files of related functions. I like to then have the module essentially do this: using packages at the top, deprecation warnings next, include the files for the functions, and then put everything that you’re exporting at the bottom. That way the module gives you an “at a glance” take on your whole package.
Don’t forget tests. Start by writing them all in one file, but after awhile break them up by topic and just include them (not that you can put an `@testset on an included file:
@testset begin include("test_this_functionality.jl") end
and then all of the @test in one file is a single testset.
About the "one function per file : functions are sometimes easier to find! Though, I admit that the number of files grows very quickly.
Reading both your posts, I begin to understand a bit more about the general workflow of developing programs. I’ve always lacked some good practice guideline. I’m primarily a scientist that happen to code. Learned by myself MATLAB a decade ago during my undergraduate studies in physics. I think that the general formation in terms of computer science is really deficient. In a 3 years program (+ master and PhD), I had 1 programming course (C). Now, I want to learn the “right” ways by learning Julia (and hopefully replacing entirely MATLAB).
I think that what stopped me in my thinking is that I was maybe aiming at “coding once”, without going back to "take my functions in file “F” and put it in a module now that I think it’s useable by other program/project. I should babysit my functions more!
Chris, I read your pst about packaging a Julia pacakge. Very helpful! (and understandale for a beginner like me!).
It is true that makes functions easier to find, until you have tons of them. I think there’s a programming language difference at play here. In Julia, small functions can usually inline, meaning that there’s no function call penalty for having tons of small functions. This coupled with multiple dispatch encourages one to write code which calls lots of small functions. The MATLAB convention was not created to handle this situation since its language did not encourage this type of development. (Think about putting every dispatch in a different file )
Definitely avoid “one function per file”. To quickly find any definition, use the methods() function. Using an IDE like Juno may further save you time, when you are ready to afford its learning curve.
If you ask a number of programmers to tell you “the right way” “about the general workflow of developing programs”, you will get the same number of different answers and maybe even more. Small chunks of wisdom can be more helpful than a complete methodology.
That’s a feasible goal, it will take some time though.
A better mentality is “coding productively” and that means many cycles of incremental coding, setting partial goals and coding against proofs of concepts, testing each block of code early in the process, before gradually combining them into ever bigger working entities, each time focusing on a single problem, so as to solve it right. In the end, you will feel like an artist, having a piece of fine art on the table, while the floor will be full of intermediate drafts. Meanwhile, the “coding once” guys may find themselves trying to figure out what went wrong and the last line of their code seems to break everything.
Sure, that’s why I putted an “s” to “way”. But as you say, each programmer probably have good ideas. It is up to me to build a workflow that suits my project. And your posts help me seeing the pathway for that.
Yeah, I think this avenue makes sense. I’m usually doing from A to Z code. It begins like good code and end as bad code because I want the results “now”!
I will try this approach of coding small functions. I was more used to larger script/functions that were far from efficient!
)