Discuss tournament exercise

[ijanos]

I see the following issues with the tournament exercise:

• At first I had no idea what the columns supposed to mean | MP | W | D | L | P. OK, I'm kind of ignorant about sports and I made an educated guess that the W is for Win and L is Loss but still it baffled me at first.
• No mention of a win worth 3 points, a draw 1 and a loss 0. I had to reverse engineer this from the test outputs. Again this could be do to my ignorance towards sports, maybe this is a common scoring system, but I believe exercism puzzles should be self-contained.
• the file formats are not explained:
  • the input format can contain comments, lines starting with #
  • what is a valid line?
  • should I expect invalid lines?
  • if the input line team1;team2;win does it mean team1 or team2 won?
• Why should the tally function return the number of parsed lines? What purpose does it serve? Why does it need a return value at all? I think the author intended the use of Result but it is not expressed anywhere and because tests use unwrap the Optional type can also be used.

And another issue, thinking about the "big picture": this exercise requires reading files, parsing them and writing data to files. I think smaller exercises with only reading and only writing files should precede this one.

[IanWhitney]

Thanks! I haven't done this exericse yet, but it sounds like it has some issues. I will dig into it this weekend.

[IanWhitney]

Points 1 & 2 could be addressed in the common readme, I think. A change there would propagate to all tracks that implement Tournament, which would be good.

I think the common Readme should also address the format of the inputs, and include examples. I'm equally baffled by it. I can not tell you which team won a game.

A lot of my confusion comes from the common description. It's unclear to me what problem this exercise is trying to get me to solve. Is it:

• Parsing of text files
• Scoring Football results
• Sorting and displaying tabular data

Or some combination of the three?

If the exercise's goal is "Parse text files", then I think the tests of invalid/commented lines are valid. That is exactly the sort of edge case you want to make students think about.

But if not, then invalid lines are an unnecessary wrinkle in this exercise.

Since this exercise is not widely supported, it's pretty easy to do a quick survey of the other implementations and see what they focus on. From there, maybe we can identify some changes to make in our version.

• Swift
• Go
• C#

All three are nearly identical.

• No input/output files. Instead they define the strings inside the test.
• Does test invalid lines
• Tally is the main API, but it returns the expected output, not a number of lines

I think if we bring the Rust implementation in line with that, while also improving the common readme (and adding a common test suite), we could improve this exercise.

[petertseng]

It's my belief that we'll have resolved all points when all three of the below issues are closed:

• https://github.com/exercism/x-common/pull/254
• https://github.com/exercism/xrust/pull/152
• https://github.com/exercism/x-common/issues/286

We may wish to open another issue to discuss the possibility of file I/O.

[IanWhitney]

I believe we've addressed this. The problem description now addresses these missing pieces, and the Rust implementation no longer uses the files. Thanks for pointing out the problems with this exercise, @ijanos !