I would like to propose an improvement to the exemplar solution for the “Poetry Club Door Policy” exercise. More specifically, its implementation of backDoorResponse. Right now it is:
const trimmed = line.trim();
return trimmed[trimmed.length - 1];
My suggestion is to simplify it to:
return line.trimEnd().at(-1);
I believe this is better because trimming leading whitespace is unnecessary here and using .at() makes the solution more concise.
I kind of understand the point you’re making, however there are things to consider:
This is a learning exercise, aimed at teaching specifically the .length property, string indexing and working with strings helper methods. Changing the “exemplar” solution would probably necesitate changing the whole exercise to include an explanation, so it’s not that simple. We should consider if there’s merit to it.
Also, using .at(-1) might be a very succinct way of doing it (there’s a reason why it’s made its way from python to other languages) but it kind of obfuscates the length so if you’re not sure how it works and if it’s not explained, it can feel as “black magic”.
Personally, whenever I see a solution using .at(-1) or .slice(-1) i would tend to approve it (assuming everything else is okay) with a note saying this isn’t the intended way to solve this exercise, but is a good way nonetheless.
That makes sense. If you haven’t seen a negative index syntax before, it would definitely be confusing, so it’s probably better to let people get accustomed to .length before introducing .at as an alternative for these kinds of cases.
Would it be worth mentioning trimStart/trimEnd along with trim?
This would be a really good addition for an approach, or mentor notes. Do you know about either of those?
The approaches in the Dig Deeper tab and the Exercise notes in the mentor guidance tab, right? I haven’t contributed to either before, but I do know about them.
Would you like to contribute to that (with our guidance of course)?
Sure! Which one would I be contributing to?
I suspect mentioning multiple trim* methods in the mentoring note might not have a huge amount of value. The audience is small and the mentors probably already know there are multiple trim methods. Approach docs have a much larger audience and tends to have higher value.
So there could be an approach using trim and another using trimEnd ? If it’s just a difference of three characters, discussing it in the Dig Deeper introduction notes instead would make more sense. Maybe it could discuss possible tradeoffs (shortness vs performance)? Or maybe have both approaches & intro notes?
I would think these would be a discussion point on the same approach/dig deeper solution.
I see! I forgot that there can be extra description below the code on the approaches. That makes more sense. How would I go about adding an approach?
Here is the contributing guide for approaches. You can see the live example of Bob, and the source for that page.
Normally we’d ask people to discuss the proposed content here, but since we do not have any approaches for this exercise yet, I am cool if you create a PR and we discuss there.
I would consider:
trim vs trimEnd / trimStart vs replace / replaceAll[index] access vs at vs charAt vs subString vs slice(-1)toLocaleUpperCase vs toUpperCase vs String.fromCharCode(charCodeAt(0) - 32)There are probably more approaches to be thought of, feel free to include as much or as little as you like. If you only want to tackle the trim + at stuff, that’s fine. Then we’ll write the rest.
I looked through the links and I think I have some idea of how to go about creating the approach now. However, I have a question: how do you generate the unique uuid?
Thanks! I have created a draft pull request here. I have added details about all three things suggested here and added an additional method of using a loop instead of trim/replace for backDoorResponse.
Right now, I’m not quite sure what to name the approach, though.
One other thing I’m not sure about is what to include in snippet.txt.
What you can do is split the different things into different sections instead of having “first approach”. Move all content to .approaches/introduction.md, same as javascript/exercises/practice/bob/.approaches/introduction.md at main · exercism/javascript · GitHub does.
## Different ways to implement `frontDoorPassword`
### Approach a
### Approach b
### Approach c
But a less structured approach is also fine with me:
## Different ways to implement `frontDoorPassword`
You can do A,
You can do B,
You can do C
We can try to see if the UI accepts no approach folder (and config), and merely an introduction.md. Then you also don’t need the snippet.
I did skim your PR. Good content so far!
I tried taking a fairly structured approach, and I think it turned out pretty well!
I can’t see if it accepts an introduction without approaches yet, though, as it seems the workflows need approval.
@SleeplessByte do you know how I can get the javascript / format / verify check to pass on introduction.md? It says “Code style issues found in the above file. Run Prettier with --write to fix.” Any help would be appreciated.