problem-specifications
problem-specifications copied to clipboard
exercism
crypto-square: Too verbose descriptions in the canonical data for C -> failing Travis build
When building tests for crypto-square in the 'C' track, naming the functions after the descriptions in the canonical_data leads to funny behavior when using indent.sh which leads to failing Travis build.
By funny behavior I mean running indent.sh on the same file leads to changes every time, which gets detected in Travis with the git diff check.
Here is the link to the pull request where this was discovered.
Curious. I have never used indent and before today had never heard of the app. I have just scanned through the doc and wonder if you can get around the issue (as an experiment) if you add
/* *INDENT-OFF* */
on the line above a function declaration that is too long, supposedly indent will be disabled until it comes across
/* *INDENT-ON* */
on a new line.
Shortening the "descriptions" may not be possible with out adversely affecting the meaning they each are trying to convey. Changes to the parameters that are governing how indent behaves may need to be changed, or another creative strategy applied.
I've given some suggestions for function name length reduction in the issue on the track, but it may well be worth continuing the discussion here in the general case - i.e.how to deal with super long test function names indicated by canonical data, where the implementation language values terseness and line column count limits.
The test name lengths can be significantly reduced by removing the description of the result and only describint the test itself.
Compare, for example, to all-your-base. The test descriptions there mention input base is zero, rather than test that when the input base is zero it results in an error that the input must be larger. (https://github.com/exercism/problem-specifications/blob/main/exercises/all-your-base/canonical-data.json#L148)
Similarly the tests here could be changed from the likes of 54 character plaintext results in 7 chunks, the last two with trailing spaces can be reduced to 54 character plaintext as this is the test case (the rest of the text describing the specifics of the result).
The fact that the expected result is specifically to have multiple chunks with two trailing spaces at the end could be added in the "comments" field, if it is needed at all (personally I think the fact is evident from the "expected" field, but it is subjective).
@vlzware @wolf99 Is this still worth pursuing? I wouldn't mind the test descriptions to be shortened. Maybe we could use the comments field to describe the result?
