Consider consistency for the exercises

[kytrinyx]

• Is there a style guide for Julia?
• Are these styles encouraged or enforced?
• Are there any conventions that we should adopt on this track for the sake of consistency?
• Can we enforce these?
• Is there a linter? Are there many? Should we use one?
• Is there a common convention for filenames? If not, what should our convention be?

Note that this is about the exercises (the test suites and code examples), not people's solutions.

[SaschaMann]

Is there a style guide for Julia?
Are these styles encouraged or enforced?

Yes, there is. Those are suggestions on how write idiomatic Julia code, but they're not enforced. They don't include anything on code formatting and indentation, though, so if that's wanted for consistency, those would have to be put together for this project. DataFrames.jl has a style guide that includes those, perhaps that can be used as a base to work from.

Are there any conventions that we should adopt on this track for the sake of consistency?

For the sake of the tests passing properly, it may be useful to include abstract return and argument types in the function/exercise skeleton. However, for beginner-level exercises these might just add confusion and distract from the core of the exercise, so I'm not sure if they should be strictly enforced. An example:

function foo(some_string::AbstractString)::AbstractString
    # your code here
    # takes a string and returns a string
end

Further I think enforcing the style guide linked above for examples is a good idea so that the learning people looking at the examples can see an idiomatic solution and can go from there.

For the tests, it can be helpful to group them into different testsets if it makes sense for the given tests. E.g. the tests for the Leap exercise could be grouped in two sets "is leap year" and "is not leap year". This improves readability and makes it easier to find which case goes wrong and runs all tests first instead of throwing the exception on the first test that doesn't pass.

Is there a linter? Are there many? Should we use one?

There is Lint.jl. I have not used it, so can't say much about it.

Is there a common convention for filenames? If not, what should our convention be?

Usually packages have a src/ directory with the actual source code and a test/ directory where tests go. Often the test-files have the same name as the source file they're supposed to test. test/runtests.jl includes a list of tests to run. More on that can be found http://docs.julialang.org/en/release-0.5/manual/packages/#package-development. From what I've seen in other exercism repos, there's usually just an example, one test-file and sometimes a skeleton in each exercise-directory, so I'm not sure if the usual package structure would add much value, besides making it more annoying to navigate.

My suggestion would be having a structure similar to this example exercise foo:
foo/foo.jl -> skeleton
foo/runtests.jl -> tests
foo/example.jl -> example solution

However, that's just an idea and not based on some kind of convention.

[kytrinyx]

I think enforcing the style guide linked above for examples is a good idea so that the learning people looking at the examples can see an idiomatic solution and can go from there.

Yeah, I think we should enforce the style guide for the code in this repository, but not for the code that people submit. We can certainly encourage them to look into it, but we shouldn't make it a hard requirement.

For the tests, it can be helpful to group them into different testsets if it makes sense for the given tests.

That sounds reasonable.

I'm not sure if the usual package structure would add much value, besides making it more annoying to navigate.

The Java track uses a different source tree structure than the rest of the tracks, but I don't know that we should do so here. If the conventions of the language are loose enough that we wouldn't be teaching people bad habits, then we should simplify as much as possible. (Also, the point of Exercism is a high degree of fluency with the basics of the language. Once you have that, it's pretty easy to accommodate your habits to larger project structures).

[kytrinyx]

My suggestion would be having a structure similar to this example exercise

That works for me. Let's do that until we come up with a good reason to do something else.

Want to document that structure in the README?

[SaschaMann]

@kytrinyx I added it in #6.

[kytrinyx]

Excellent. I think that #6 closes this. I'll add the magic comment to that issue so this will get closed when it gets merged.

[SaschaMann]

It would be good to also have a convention for code formatting which the Julia style guide doesn't provide.

There is no widely agreed-upon standard, so it differs from package to package.

Perhaps we could stick to the same Formatting Guidelines that is used for the Julia core codebase?

[kytrinyx]

It would be good to also have a convention for code formatting which the Julia style guide doesn't provide.

You mean for the code in this repository, or that we suggest to people for their solutions?

[SaschaMann]

In this repository for the examples.

[kytrinyx]

I think that is a really good idea. The same formatting rules as for the core Julia codebase seems like an excellent choice.

[SaschaMann]

@kytrinyx added it to readme in #18. If you could take a look checking for phrasing/spelling errors, that would be appreciated.

[kytrinyx]

Sweet, I'll take a look.

[Teo-ShaoWei]

Good day,

Before anything, great work done for the Julia track on Exercism! The questions are carefully set up by @SaschaMann and it has been a joy working on them so far.

I am looking at contributing to the community but there is one thing I need clarifications... All the method template uses input parameters that have declared types. Looked around the repo for the motivation and I chanced upon it here.

Since it wasn't a strong preference, could I counter-propose that we remove type declarations instead? for the example above:-

function foo(some_string)
    # your code here
    # takes a string and returns a string
end

The rationale is that It should be clear from the test cases on the type of the input parameters. This is how dynamic languages like Python/Ruby etc work, and allows us to avoid ugly Java-ish syntax like some_string::AbstractString where the information string is repeated twice.

My opinion is that in Julia, unless we are coding an interface function, which expects many methods of some types to implement it, it makes sense to state the type. For one-time functions like this, there is no ambiguity when Julia does dispatching, and thus it is better to leave it out.

More importantly, some university CS programmes are moving away from stronghold like Java into Python because of the beginner-friendliness of the syntax. It will be helpful to provide the Julia track if we can demonstrate that similarity to Python.

For your consideration, please. Meanwhile I will work on porting some exercises from other track here =)

[SaschaMann]

Hey,

thanks for the feedback! That convention was made before we actually implemented any exercises. Many exercises don't even follow it anymore for various reasons. The original motivation was that the user wouldn't have to look at the tests at all.

You're right that the type declarations aren't needed in most cases here. Some exercises don't have a skeleton at all because it would make the exercise trivial.

Perhaps we should decide it on an exercise-by-exercise basis but default to method signatures without types.

Thanks for bringing this topic up again!

---

My opinion is that in Julia, unless we are coding an interface function, which expects many methods of some types to implement it, it makes sense to state the type.

Perhaps there should be an exercise that explicitely requires writing a module with exports etc. It's a fairly important part of writing reusable Julia code. I'm not quite sure which exercise would be a good candidate for this, though.

---

The questions are carefully set up by @SaschaMann and it has been a joy working on them so far.

Glad to hear that! @aawray / @andrej-makarov-skrt deserves credit for a lot of exercises as well.

[Teo-ShaoWei]

Perhaps we should decide it on an exercise-by-exercise basis but default to method signatures without types.

Ok noted on the preference, I think this is good judgement.

Perhaps there should be an exercise that explicitely requires writing a module with exports etc. It's a fairly important part of writing reusable Julia code. I'm not quite sure which exercise would be a good candidate for this, though.

This is a good idea. I will be sure to look out for bigger problems in the ecosystem. I hope to import problems from the dynamic language tracks first, but once that is done, the bigger problems should surface themselves from the more enterprise-y languages.

Glad to hear that! @aawray / @andrej-makarov-skrt deserves credit for a lot of exercises as well.

Thanks for the exercises everyone =) I will get the rest done, and help out the community while I am at it.

[SaschaMann]

I'll update the README and move that discussion about the module-exercise to another issue