Improve Concept Exercise: Savings-Account (Constants)

[andrerfcsantos]

Getting Started

If you have not yet contributed to concept exercises before, this task requires some upfront reading to acquire the necessary background knowledge.

Here you can read about what Concept Exercises are and how they are structured:

• What are Concept Exercises?
• Concept Exercises
• Concepts

Also, be aware of these general guidelines:

• Exercism Markdown Specification
• Exercism Formatting and Style Guide

Goal

There is an existing concept constants and an existing concept exercise savings-account to teach that concept. It currently has the status wip so it is not available to students on the website. The goal is to improve (and if necessary extend) this existing exercise so it can go live on the website. See also #1583. It is probably a bit hard to make an engaging exercise about constants but we should try.

So the main objectives in this issue are

• ensure all learning objectives mentioned below are covered int he concept in a meaningful way
• improve the exercise story to make it more engaging (see also savings-account: tweak design #1583, the link in there contains more details on what is meant by this)
• ensure the exercise tasks make sense/are well written and cover all the learning objectives, add/remove tasks as needed

If someone wants to work on this but feels the current story/exercise is hard to fix, feel free to change it completely if you have a better idea. The folder/exercise name can be changed to whatever we want. As long as we keep the same UUID in the config, that does not cause any issue (we did it for other exercises in the past already).

Learning Objectives

The following topics should be covered by the concept and then be practiced in the exercise.

Re constants in general:

• what types of constants exist in Go
• how do numeric constants work (can take on the type they need to have to "fit in")

Re enums:

• there is no "enum type" in Go (so far)
• given a type definition, create blocks of constants with constants of that type that act as an enum
• show the use of iota as a helpful way to give values for the constants easily.

Sidenote: The instructions.md file of the exercise and the concept can have the same content. Also the about.md of the concept does not need have much additional content compared to the instructions.md file at this point.

Prerequisites

• type-definitions
• (others might be necessary depending on the concrete exercise)

These prerequisites should be listed in the root level config.json entry for the exercise.
The prerequisites above are a baseline of the prerequisites that might be needed for the exercise.
When implementing the exercise, feel free to add more prerequisites if the exercise needs them.

Resources

Some links that might be helpful as a starting point and/or for the links section of the concept:

• Go Blog - Constants
• A Pattern For Enums in Go
• Working with Enums in Go
• Safer Enums in Go

How to proceed

1. First accept this issue by saying "I'd like to work on this" (no need to wait for a response, just go ahead).
2. Use this issue to discuss any questions you have, what should be included in the content and whatnot, and to collect more reference material.
3. Create a PR and set "exercism/go" as reviewers. Additionally, you can write in #maintaining-go on Slack that your PR is ready for review. Once you incorporated any critical feedback that the reviewer might give you and the PR is approved, it will be merged by a maintainer.

[junedev]

FYI There is a wip exercise in the repo already that covers parts of what is listed above: savings-account, concept constants.
The exercise would probably need quite some improvement so it might be better to start from scratch. I just wanted to mention it.

Nevertheless, it might be worth thinking about sticking with constants as concept name (and adding some non-enum related into about constants) instead of creating enum as a concept which does not exist in the language. In the JavaScript track we also discussed this issue of "concepts the language lacks" and decided to better but the things that exist instead in the concept tree rather then the names of the things that don't exist but people might look for. Both ways have pros and cons of course. @andrerfcsantos WDYT?

[andrerfcsantos]

Sound good.

I agree with renaming this and making sure we name concepts just after things that are on the language.

If you agree, we can change this issue to be the improvement of that exercise (if any) and we make sure that both constants and this "enum" pattern are well covered.

[junedev]

If you agree, we can change this issue to be the improvement of that exercise (if any) and we make sure that both constants and this "enum" pattern are well covered.

Yes, sounds good.