Variable naming

I had a ton of fun doing the Pharo track, but one thing that consistently confused was the fact that the tested value is always named “…Calculator”. In some cases, this works, but in many cases it doesn’t:

  • twelveDaysCalculator
  • reverseStringCalculator
  • isbnVerifierCalculator

Would there be any objection to just using the class/exercise name? So:

  • twelveDaysCalculator becomes twelveDays
  • reverseStringCalculator becomes reverseString
  • isbnVerifierCalculator becomes isbnVerifier

Alternative, you can have reverseStringCalculator become stringReverser if that is more in line with conventions.

I can’t answer on the “why”, but it seems to be part of the exercise generator code

Right, thanks for spotting! @Bajger would you mind chipping in?

Hi Erik! Glenn is correct - ExercismExerciseGenerator is class responsible for generating test classes and methods out of problem specification directory. Specifically method ExercismExerciseGenerator >> testVariableName as mentioned above.
It would need to be changed to a new name and test methods need to be regenerated. In the end it should not be a big deal, there are just some circumstances that need to be considered (e.g. exercise problem specification changed meanwhile on exercises). If “all goes green” I’ll try to create PR next week.
To name itself: my suggestion would be to use: aTwelveDays or aReverseString - this is convention in Pharo to determine whether variable is instance of some class. But it could be as suggested by you as well. Thoughts?
PS: I’m curious about any catchups during your experience :slight_smile:

1 Like

I’m perfectly fine with that!

Nothing much actually, it was a lot of fun! It’s mostly the getting to know the IDE bit that was initially a bit hard, but that’s not on you.