Coming from a Lisp background I really like using function names which end in ? or in p to emphasize that the function is returns a Boolean answer a question. Such as even? or evenp to ask whether the given integer is even. Is such a naming convention ill-advised or frowned upon in Scala?
First you should note, that naming a method even? is not allowed in Scala:
@ def even?(a: Int): Boolean = a % 2 == 0
(console):1:9 expected (Semis | &"}" | end-of-input)
def even?(a: Int): Boolean = a % 2 == 0
^
You can work around that by putting the name in backticks, but you’d also have to do that on every usage. Alternatively, even_? would be allowed. I haven’t seen one of these naming conventions used in Scala, nor the one with an added p. So I personally wouldn’t use them.
The only languages where I have seen this convention are all dynamically typed. With a statically typed language like Scala, I feel like there is little need to signify the return type of a function by its name.
1 Like
BTW the Scala naming syntax (not conventions) has always been a mystery to me. Is there a good reference specification for naming? I know that naming influences associativity, method applicability, infix-ability, and sometimes other semantics.
Not really – frankly, naming habits have evolved significantly over the past ten years. For example, for a while there was a passion for making use of Scala’s ability to use Unicode freely, which led to heavy use (in some opinions serious overuse) of symbolic operator names, as seen in Scalaz. Most recently there has been a backlash against that, and I think a growing consensus (which might even get reified in Scala 3?) that symbolic operators should always have spelled-out names as well.
But beyond that, there are a few rules, but little else. $ is reserved for internal use, and :, IMO, should be reserved for its use in mucking with method associativity. There’s a growing tendency to use category-theory names for things when appropriate, and folks are encouraged to use method names from the standard library when you’re doing the same sorts of things on your own types. But I don’t know of any real spec, and at this point I suspect it’s much too late to try to foment one…
When I say, specification, I don’t mean a convention description, but a specification of what the compiler allows for forward compatibility.
Lexical rules are here: https://www.scala-lang.org/files/archive/spec/2.12/01-lexical-syntax.html
Naming conventions are here: https://docs.scala-lang.org/style/naming-conventions.html (although slight deviations are often seen)
Naming like even_? is used to some degree in Lift’s codebase (www.liftweb.net). I find it easy to use/understand and have adopted it for our codebase.
1 Like
The guideline I learned is to make it look readable in an if-expression, like:
if(set.isEmpty) …
Sure, but not everything fits nicely with the is/has-convention, especially when using boolean variables. It sometimes affects the semantics if trying to shohorn it everywhere.
IMHO I find this:
if (sendEmail_?) …
if (restrictToCurrentYear_?) …
more readable than whatever some creative is/has-counterpart would be.
I’m guessing that restrictToCurrentYear_? is what I would write as isRestrictedToCurrentYear, and I don’t know what sendEmail_? is supposed to mean. Does it mean email should be sent? Or that email has been sent?
I agree with curoli that it is best to stick with the isEmpty and nonEmpty pattern. So it would be isEven and nonEven (or isOdd). You could also use notEven or, if you want to be more verbose, isNotEven.
1 Like
In both cases they mean “doStuff”, as in imperative, where true is “should” and false is “should not”, like in “doRestrictToCurrentYear” and “doSendEmail”. So - IMO - is/has often doesn’t express the precise meaning/intent, hence I prefer _? syntax. You are then more free to name the variable as precise as you like without worrying about if is/has messes up the meaning.
restrictToCurrentYear_? I’d interpret that as doesTheObjectNeedToBeRestrictedToCurrentYear And I’d say that sendEmail_? means doWeWantToSentEmail and to have the meaning “has email been sent” I’d name it sentEmail_? (I hate the _ but I can live with it)
What about the naming pattern of having two names for the same thing in two different concentric scopes? I.e., if the inner scope needs to eclipse the outer, the use the same name, but if you need to see both, what to name the inner? In OCaml we often use a and a' and a'' etc. I sometimes use a1 and a2 in Scala, but that is really ugly if a1 is a parameter to the function and thus visible to the outside.
Is there a naming convention for the binary and varargs versions of the same function? I’m looking for something like f and f*
It’s not a common situation – I’ve usually seen folks just implement the varargs version, and maybe handle the binary specially in code. That is, the signature is something like:
def myFunc(f1: Foo, f2: Foo, fs: Foo*) = ...
So there are at least two parameters, and may be more; the implementation of myFunc looks at whether there is anything in fs and reacts accordingly.
There may well be cases where that’s inappropriate, but I don’t think they’re common enough for naming conventions to arise…