The problem description uses nickname , but the exercise code defined nick_name .
This update renames the method to nickname for consistency between the description and the code.
Please review.
Someone else had started working on the same issue, but progress had stalled at the draft stage.
Note that exercise has over 2,000 completed solutions. Changing the test will break all of those.
I understand the concern. How about updating the problem statement to use nick_name instead?
Since this exercise is aimed at beginners, I thought it might be clearer if the statement and the code matched.
I would appreciate your consideration.
Not a Ruby maintainer, but I think updating the concept exercise’s instructions to match the test suite would be appropriate and avoid breaking solutions.
cc @kotp
You say “this update” but I do not see a link to “this update”. Can you edit and link to that, so it is easy to get to? I think it might be: exercism/ruby#1769 (as evidenced partly from the same/similar first comment there).
But it would be good to have this located in your original message in the forum for ease of navigation.
For Ruby, it is a concept exercise, so yes, having more stringent consistency on how to read and interpret things is important.
We would want to do this in a way to avoid breaking solutions that exist, and the files that we would be looking at are (in the exercises/concepts directory):
chess-game/.docs/hints.mdchess-game/.docs/instructions.mdchess-game/.meta/exemplar.rbchess-game/chess_game.rbchess-game/chess_game_test.rbThe prior PR’s that exist concerning this can superseded if we can solve this in a non-disruptive way with an improvement.
The observed inconsistency seems to be currently resolved during mentoring (not that I can see this any longer, to know for sure), but we have had less than a handful of reports of this being a nuisance, from what I have seen. But it definitely could save some cycles for students and mentors to not have to deal with it at all.
It is not improper to use it as a single word or as two words, but either way we go, likely now driven by the tests, we can make it consistent.
As an example, in the test file, where we reference “nickname” in the test title, and the difference of two words in the code, I would go from this:
def test_correct_nickname_for_2_letter_last_name
assert_equal "LILI", Chess.nick_name("Lisa", "Li")
end
to this:
def test_correct_nick_name_for_2_letter_last_name
assert_equal "LILI", Chess.nick_name("Lisa", "Li")
end
Thank you for bringing this up @lemonade-37 .
If you are going to do the work for it, we can reference the other two(?) pull requests that have not moved, so they know that it is being attended to, and I can close the draft from January.
I cannot find it anywhere as two nouns, but Google Search Trends does list it as something people search for. nickname does seem to be the by far more popular way to write this:
Nickname versus nick name is also listed as an example of false splitting in Rebracketing - Wikipedia. Nickname is the correct or at least most popularly accepted form. l didn’t notice nick name wasn’t nickname when I did this exercise, and as a native American English speaker, it doesn’t bother me. We should be consistent with our code examples and tests though.
I apologize. I copied the pull request description verbatim and forgot to edit the text.
“This update” refers to this pull request. I’ve also added the URL to the original text.
Thank you again for reopening the pull request.
I have corrected the method name in exercises/concept/chess-game/.docs/instructions.md to “nick_name” as instructed.
Additionally, I have unified the test case names in exercises/concept/chess-game/chess_game_test.rb to use “nick_name”.
What should we do about the “nickname” notation in the text within exercises/concept/chess-game/.docs/instructions.md and exercises/concept/chess-game/.docs/hints.md? Should we change it to “nick name”?
I don’t think it’s necessary to change the text much, as I believe consistency in the method name alone should prevent confusion.
When I looked at this quite a while ago, I realized that the nick_name difference from “nickname” in the writing almost naturally reinforced what was the description and what was the actual code, the method name.
Therefore, I am a little bit torn about it, since it serves a purpose, even though it is, OK, not strictly proper, but wordnet does know both, and points to the same thing, with the allowance that it is a “false split”, as @BNAndras brings up, correctly.
If we correct the split, then all submitted exercises would fail. We could alias it, presenting corrections in the documents, while allowing for it in the tests, if we wanted to do that. Therefore, no failed tests for existing successful submissions, and yet, students can solve it more “properly” in alignment with formal English.
What do you think about that solution? Documentation does single word “nickname” and even referring to the method name, while the tests are a little “permissive” with this.
We might have to consult with @Meatball in regard to his work on the test generator recently, as well.
Are we confident that there would be more confusion if we picked nick name over nickname consistently? As a native speaker, I don’t want to speak for others, but both forms are clear to me. So it’s not an issue if we say nick name. The issue is we have contradictory method names. The tests should drive the implementation so I would update the instructions, which has the additional benefit of not invalidating existing solutions.
They are both clear to me as well, and the difference from “nickname” as a descriptor and the technically named nick_name matches the two word methods in the solution and tests as well.
It is why to some extent this long time known discrepancy has not been tackled. We do not hear about a problem with it very often.
For sure the writing itself should be consistent, and the code itself is naturally consistent (other than maybe test title names), as they they would break otherwise.
I personally don’t feel that breaking old solutions should be considered. If we want to ensure no costs are incurred, [no important files changes] could be used to accomplish that.
That said, I don’t have a real preference for how it is resolved, as long as it becomes consistent 
The test generator is only for practice exercises so for this it wont matter. My stands is that this has already be discussed in another forum thread, and I think we said go there but said user didn’t complete the pr. So my stands is still the same that we can go ahead.
I vote for changing it to nickname.
Ruby’s test runner is super fast so it probably won’t incur a cost to do 2k updates. And I don’t think many people will be revisiting this as its a Concept Exercise. (I’m always much more in favour of breaking concept exercises to make them right for future students, than I am of practice exercises where people come back and refactor more, and there’s less direct learning to be had).
@lemonade-37 Want to amend your PR to go the other way?
In my opinion, unifying it under nickname is the best approach.
Even if there are technical difficulties, I believe we should at least resolve the inconsistency between the instructions and the method name in the code.
I have committed a change that renames nick_name to nickname.
I would appreciate it if you could review this pull request.
I’ve confirmed that the pull request has been merged.
I’m truly grateful to everyone who reviewed it and shared their thoughts.
Thank you very much!
There’s another draft PR ( #1738 ) related to this change, but it seems to be conflicting and inactive.
Out of curiosity, do you have any plans for how to proceed with that PR?
Make a comment in the pull request that this exists, and I will click through and deal with it. (I have done this for you, see below message.)
I have approved and merged PR exercism/ruby#1769 but I will see any activity there still.
Well, I have done the niceness, so you do not have to.
Got it, and thanks for taking care of this!
I really appreciate it.
I’ll mark the Topics as 
.
