excercism_go_mentor_notes.md

Two for:

Well done! We can avoid code repetition by assigning the value "you" to name in the if block and then returning after the if block. Short and simple code is more readable. Find the minimal condition to make the code DRY (Don't Repeat Yourself).

Difference:

The solution looks clean. However, instead of looping through the numbers, we could use existing mathematical formulas to compute square of sum and sum of squares for a given number n. Please try implementing this using the formulas.

More often we face problems that are already solved with an optimal solution, we do not need to reinvent the wheel every time we write a new program.

Also, for simple problems such as these we can avoid using math package and the subsequent type conversion.

Very well done!

Appreciate that you researched and used mathematical formulas to come up with the optimal solution.

Keep up the good work!

Very well done! We can simplify the implementation even further if we use map[rune]bool instead of map[rune]int

Rain:

• The strings.Builder is helpful when concatenating a lot of little parts to a string. For this use case, the += operator is simpler, faster and uses less memory. This can be verified by running the benchmarks as described in the exercise instructions.

Well done! Instead of calculating the modulo operations twice for every number. If we can move the if block in L12 to L37, we can simply check if sounds is empty. We can also run benchmark to understand which approach is efficient.

Scrabble:

Well done!

Few suggestions:

• if we use map[rune]int to store the scores we can avoid the type conversion at L37.
• unicode.ToUpper is slightly faster than strings.ToUpper. Please run the benchmark tests with different approaches to see which is more efficient.
• There is yet another approach to solve this problem by using a switch case instead of map which is more performant. Please do try that out during your leisure time. You can run benchmark on different implementations to understand which is better.

Very well done!

However, there is yet another approach to solve this problem by using a switch case instead of map which is more performant. Please do try that out during your leisure time. You can run benchmark on different implementations to understand which is better.

Happy coding!

Invert if:

• To simplify, please try inverting the if condition handling the error case, then get rid of the else branch by returning within the if. A Go proverb says "The happy path is left-aligned", meaning the normal flow of control follows the left-hand margin, and only exceptional or error cases are indented. In Go, it's conventional to use multiple returns, returning as soon as possible from a function. Typically edge cases and error cases are handled as early as possible, leaving the happy path aligned to the left edge. For a nice explanation of this practice, see Align the happy path to the left edge, or watch the talk that he gave on the same topic.
 Small case error:
• Error strings in Go are typically not capitalized, and do not contain punctuation. This is because in Go error strings are often chained together, providing a sort of breadcrumb trail of what led to the error. Punctuation and capitalization make the resulting error messages look weird.
 Errors new: Prefer errors.New over fmt.Errorf for error messages that don't need interpolation, as it avoids parsing the message for placeholders.

The rune to byte conversion is safe here, because the input string contains only ASCII characters. Go runes can consist of multiple bytes, though, which can cause trouble when dealing with non-ASCII characters.

For more on this, read Strings, bytes, runes and characters in Go on the Go blog.

To see what happens when non-ASCII characters are used, add this test case:

{
	s1:          "aüa",
	s2:          "aÃa",
	want:        1,
	expectError: false,
}

rawMins := hours*60 + mins
absMins := (rawMins%dayMins + dayMins) % dayMins
return Clock{(absMins / 60) % 24, absMins % 60}

589, 25mbps

fn main() {
    Clock::new(2, 20).add_minutes(-3000);
}

Very well done!

Please go through the community solutions to know more on the various approaches to solve the problem.

But if you want to let it stand as is, let me know and I will approve it. Or you may submit another solution refactored to be more performant.

Very well done!

We could use constants to store 1_000_000_000. LGTM otherwise.

Clock:

Well done!

IMO, since Add and Subtract anyway expects a Clock in return, it would be better if we use New to create a new clock, we can also avoid calling format.

LGTM otherwise.

I leave it to your discretion though.

Please go through the community solutions to know more on the various approaches to solve the problem.