The convention in Kotlin is for boolean properties to start with is. This extends to its automatic recognition of properties in Java classes - if a class has an isCheap and setCheap method then it will automatically get a isCheap var. This seems to be a common convention in C# as well.
In Java I usually would not do it - there, it's conventional for the getter method to be called isCheap while the backing boolean is just called cheap.
So which one to use is entirely going to depend on what language I'm writing.
For functions, I think it depends as well.
If it were isCheap(thing) then I'd keep the name isCheap. Actually, I would try to refactor it such that it's just an isCheap property on Thing if possible. But if I'm working in something functional where I can't really do that, sure - isCheap(thing) makes some sense. But in the current form in that example, I'd probably call it determineIsCheap or similar - the thing being passed in isn't the thing where you're determining whether it's cheap, but more a collection of other properties about some object which is not itself provided.
The convention in Kotlin is for boolean properties to start with
is. This extends to its automatic recognition of properties in Java classes - if a class has anisCheapandsetCheapmethod then it will automatically get aisCheapvar. This seems to be a common convention in C# as well.In Java I usually would not do it - there, it's conventional for the getter method to be called
isCheapwhile the backing boolean is just calledcheap.So which one to use is entirely going to depend on what language I'm writing.
For functions, I think it depends as well.
If it were
isCheap(thing)then I'd keep the nameisCheap. Actually, I would try to refactor it such that it's just anisCheapproperty onThingif possible. But if I'm working in something functional where I can't really do that, sure -isCheap(thing)makes some sense. But in the current form in that example, I'd probably call itdetermineIsCheapor similar - the thing being passed in isn't the thing where you're determining whether it's cheap, but more a collection of other properties about some object which is not itself provided.Interesting, thank you!