Problem-specifications: Consistent naming of properties that return boolean value

Created on 22 Mar 2017  路  10Comments  路  Source: exercism/problem-specifications

While working on writing test generators based on the canonical data, I noticed a small inconsistency. The isogram canonical-data has named its property isIsogram, which makes for a nice, readable function name. However, the leap canonical-data has named its property leapYear, which makes for a slightly less readable function name. I would much prefer to use isLeapYear, which looks clearer to me.

Of course, I could modify my test generator to prepend the "is" part, but maybe we should strive to standardize the naming for boolean properties?

Most helpful comment

My vote goes to: isLeapYear, which is think best communicates what we expect the function that implements it to do.

All 10 comments

I also prefer isLeapYear, @ErikSchierboom, but I think that naming conventions have a lot to do with the language and personal preferences, so I'm not sure if it is worthy a tabs vs spaces war to standardize it (two spaces using Vim, of course 馃槃 ).

Anyway, I'll list some alternatives that conform to the schema as a conversation starter, so that we can see if it is contentious:

  • leap
  • leapYear
  • IsLeap
  • isLeapYear
  • isBissextileYear
  • isAnIntercalaryYearInTheGregorianCalendar
  • f

My vote goes to: isLeapYear, which is think best communicates what we expect the function that implements it to do.

@rbasso said:

two spaces using Vim, of course

I knew you were a right-thinking person. ;)

... also ... definitely f.

We can use a standard here if it will help comprehension. If a test generator is able to figure things out from seeing that expected is of type boolean, then great. If some language's test generators need a small exercise-specific portion, then the consistency might help the implementor.

I acknowledge that languages will want to use different names for their functions, such as is_leap_year or leap? or leapp (repeated p intentional). Note that is true no matter what name x-common chooses.

"naming conventions have a lot to do with the language" 馃憤

As either way we decide, some languages will end up preprocessing the resulting names, maybe we should figure out how many languages use each convention?

Ruby's naming convention is to use '?' and not a prefix.

So would having a standard here help or is the benefit not great enough? I'm not entirely sure if the benefit is great enough.

I think we should have a standard so that they all look the same. I would vote for isLeapYear.

Does this also make sense for:

luhn: valid,
custom-set : equal
clock : equal
queen-attack : canAttack
dominoes : canChain,
triangle : equilateral, isosceles, scalene

canAttack/canChain might be a better names than isAttackable/isChainable

Perhaps this would make a better guideline than a strict rule?

@Insti I think that would be best,

Okay. Let's close this issue and just remember to keep an eye out for possibly non-optimal boolean properties.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

budmc29 picture budmc29  路  3Comments

kytrinyx picture kytrinyx  路  5Comments

wolf99 picture wolf99  路  4Comments

kytrinyx picture kytrinyx  路  4Comments

bubo-py picture bubo-py  路  4Comments