Regenerate READMEs from problem-specifications commits#384
Merged
coriolinus merged 4 commits intoexercism:masterfrom Nov 7, 2017
petertseng:readme
Merged
Regenerate READMEs from problem-specifications commits#384coriolinus merged 4 commits intoexercism:masterfrom petertseng:readme
coriolinus merged 4 commits intoexercism:masterfrom
petertseng:readme
Conversation
Avoid confusion with 2-digit numbers `23` vs domino `[2|3]` exercism/problem-specifications#972
The description currently specifies that buckets are represented, in both the input and the output, as strings. This seems overly constraining. Consider those tracks that wish to represent these buckets as variants of a tagged union or of an enum for the purpose of better type safety. These tracks have these options in order to do so: * Accept the problem-specifications README as is, but act in contravention of it. But it is confusing if the README contradicts the tests. * Create a custom description.md. But this is a little unfortunate because only two lines need to change, and it adds extra maintenance burden to have to maintain the custom description.md. Consider that if this description.md changes, the changes will probably need to be copied to each custom description.md * Add to .meta/hints.md saying something to the effect of "ha ha ignore the above text about using Strings, we're using tagged unions / enums" so that this will be appended to the description. But it seems too strange to have a README contradict itself. * Other solution I did not think of. Thus, it seems it is best to remove the specification of the buckets as a string so as to allow the flexibility. For the purpose of consistency, all other types have been removed as well, otherwise it would invite (very reasonable) questions about why all inputs/outputs except the buckets have types given. It is surmised that this leads to no real loss, because it should be obvious that sizes, number of moves, and number of liters are all numeric values. exercism/problem-specifications#990
One might assume that we can consider a CI check that there are no trailing spaces, but we have to be careful because some embedded strings that serve as example outputs are expected to have trailing spaces. The currently only example is ocr-numbers. One might consider a CI check, but simply exclude that file. exercism/problem-specifications#995
petertseng
added
the
sync/readme
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.