https://kotlinlang.org logo
#announcements
Title
# announcements
j

james

11/26/2019, 12:31 AM
I'm looking for some guidance around boolean naming conventions in Kotlin. I'm working with an older java class which is populated from an API, where the API returns something like
canEditProfile
and the java class has a field named
isCanEditProfile
. I'll have a new kotlin class which exposes a few of these fields, and I think the name
isCanEditProfile
seems a bit odd, so I'm looking for alternatives for this and a few other similar booleans. I know
is*
and
has*
are commonly accepted boolean prefixes in the java/kotlin world, I'm just wondering if
can*
is also acceptable in this context?
r

Rolando Lopez

11/26/2019, 12:45 AM
We use can*. But really as long as you’re consistent within your team
👍 2
a

Adam Powell

11/26/2019, 12:54 AM
We run into this in Android API review a lot. We often recommend keeping "is" and rearranging the grammar to make sense, so in this case we might suggest
isProfileEditable
2
But local consistency with existing context in the code often wins in disputes
Nothing wrong with "can" though, unless you're trying to keep a consistency across a large surface area
j

james

11/26/2019, 1:02 AM
thanks guys 🙂