Add Resistor Color Trio Exercise

[soumitradev]

Added previously unimplemented Resistor Color Trio Exercise

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@f3b9406). Click here to learn what that means.
The diff coverage is 98.57%.

@@            Coverage Diff            @@
##             master     #193   +/-   ##
=========================================
  Coverage          ?   96.41%           
=========================================
  Files             ?      120           
  Lines             ?     1199           
  Branches          ?        0           
=========================================
  Hits              ?     1156           
  Misses            ?       43           
  Partials          ?        0

Impacted Files	Coverage Δ
...ercises/resistor-color-trio/resistor-color-trio.jl	0% <0%> (ø)
exercises/resistor-color-trio/example.jl	100% <100%> (ø)
exercises/minesweeper/runtests.jl	100% <100%> (ø)
exercises/minesweeper/example.jl	100% <100%> (ø)
exercises/resistor-color-trio/runtests.jl	100% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f3b9406...b45ad53. Read the comment docs.

[SaschaMann]

Thanks for adding the exercise!

I like that you commented the example solution :)

I think this exercise is a really good candidate to go beyond the canonical data and use Unitful.jl. Returning units as strings seems rather unjulian and it would be a pretty nice non-core exercise for people to play around with.

Do you want to you convert it to use Unitful and provide a Project.toml & Manifest.toml file for a reproducible environment for the student? I'll leave the decision up to you, I think the exercise is interesting as it is already, too.

The repo's runtests.jl file can't really handle dependencies yet, but I can fix that afterwards as long as the tests of this PR pass locally.

--

Two things about the coding style:

• In Julia it's preferred that variables have snake_case names rather than camelCase. It only affects internal variables here, so it's not a big deal, but it would be best if you can adjust them
• Please add a trailing newline to all files. That makes it easier to read diffs/changes later on. Most editors have a setting to do this automatically.

[soumitradev]

I think this exercise is a really good candidate to go beyond the canonical data and use Unitful.jl. Returning units as strings seems rather unjulian and it would be a pretty nice non-core exercise for people to play around with.

Do you want to you convert it to use Unitful and provide a Project.toml & Manifest.toml file for a reproducible environment for the student? I'll leave the decision up to you, I think the exercise is interesting as it is already, too.

Sure! I'd love to do that in the future and work on making the exercise more interesting and clear, but for now, I think I'll leave that for later when I have time.

Two things about the coding style:

• In Julia it's preferred that variables have snake_case names rather than camelCase. It only affects internal variables here, so it's not a big deal, but it would be best if you can adjust them

Don't the Code Formatting Guidelines on the README suggest camelCase for types? Which one should I use?

• Please add a trailing newline to all files. That makes it easier to read diffs/changes later on. Most editors have a setting to do this automatically.

Sure, I'll just do this in the next commit along with the case change I mentioned.

[SaschaMann]

Sure! I'd love to do that in the future and work on making the exercise more interesting and clear, but for now, I think I'll leave that for later when I have time.

Okay, then I'll merge this once the formatting/style changes have been done and you can pick it up later whenever you want.

Don't the Code Formatting Guidelines on the README suggest camelCase for types? Which one should I use?

Type names, e.g. Int, String, struct MyOwnType; end should be upper camel case. Variable and function/method names should be lower case with additional underscores if needed.

So for example in your code:

function label(colors::AbstractArray)

    # Set the color-number converter list
    colorKey = ["black", "brown", "red", "orange", "yellow", "green", "blue", "violet", "grey", "white"]

AbstractArray is a type name -> it's upper camel case
label is a method/function name -> it's lower case
colorKey is a variable name -> it should be lowercase colorkey or color_key

[SaschaMann]

Thanks!

@soumitradev Please leave a short comment whenever you add a new commit that addresses changes to a PR. Otherwise GitHub won't send a notification and it might go unnoticed.