Scala is a wonderful language, with a specification of a size comparable with that of Java. Overall, the specification is simpler than C++. Why then do some feel intimidated by its expressiveness?
Scala can generate complex constructs. There are some features of the language that, if not used properly, can negatively influence one's perception of its simplicity and generate a waste of many an hour of a frustrated developer.
Newcomers from simply typed, object-oriented, structured languages do not have a full grasp of all the features of scala and their effects or benefits, and they may be very surprised if others on their team use them.
One thing to have when starting or using scala is a readily available bible. I recommend "Programming in Scala", the .pdf version, an easily searcheable language reference.
The scala style guide is very good. Here we will describe the advanced features of the language, which are aimed at library-developers and should not be abused.
Do not abuse:
- many constructors for the same thing. These come in many kinds, from this() to apply() in a companion class to implicits
- anonymous functions everywhere
- the def f()()()() notation
- _ (underscore)
- do not chain many function calls in the same line.
- operators
- implicits visible outside of a class
- complex type restrictions
- complex higher types
Avoid re-defining operators or defining new ones. For instance:
// this is mean
override def + (that:String) = this - that
// coming up with funny operators
def --++==--++ = 5
Basically, don't define operators unless they make a lot of sense as applied on the data type at hand and don't come up with new ones, especially if you're not a DSL designer...
You could use implicits inside a class or object, to simplify the code and learn. DO NOT make them visible outside the class, unless they're used for pimping.
The wildchar is used in many circumstances:
- currying: f _
- ignore types: List[_]
- ignore values in pattern matching: case Student (_,a) => ...
- match anything: case _ => ...
- stand-in for parameters in lambda sugar-coated syntax: list map (_ + 2)
Avoid using many of them on the same line or small scope.
When defining higher order types, stay away from complex type restrictions.
// this is typical
val students : List [A <% Student]
// this is ok - although you should use Option rather than null
class NoStatic[T>:Null<:AnyRef] {
var lazyValue = null
}
//this is to be completely avoided
def combo[AA <: A >: B <% String <% Int : M : Ordering] = 0
Once you pickup the functional style, composing functions becomes the norm...No more than 2 map()s in the same line. Note that getOrElse is a type of map for this purpose.
//This is borderline comprehensible:
SystemProps.sPatProps.find (_.patcomp.pattern.matcher(name).matches) map (_.value) getOrElse System.getProperty(name)
// not so here - actually here an inline lambda is abused
o._2.asInstanceOf[List[scala.xml.Elem]].filter(zz => XP.stareq(zz.label, tag)).map(x => { val t = (x.asInstanceOf[T], children(x).toList.asInstanceOf[U]); println("t=" + t); t }).toList
//here the name is very useful and excuses the rest of the line
def messagesById(id: String)(f: => List[(NodeSeq, Box[String])]): List[NodeSeq] = f filter (_._2 map (_ equals id) openOr false) map (_._1)
//not here, though
val ret = (Box(connectionManagers.get(name)).flatMap(cm => cm.newSuperConnection(name) or cm.newConnection(name).map(c => new SuperConnection(c, () => cm.releaseConnection(c))))) openOr { ... }
Generally, higher-order types are already provided for you, in the collection libraries. If you need your own Group[Student], then you should keep it simple.
The example may look comprehensible, but using it may cost a lot of time...
trait WRGraph[N <: GNode[N, L], L <: GLink[N]] extends GNode[N, L] { this: N =>
...
}
It's great only for DSLs but may confuse one to have to call add (1) (2) when all day long I use sum (1,2)...
//this is customary
def using (r:Resource) (f: Resource => Unit) = ...
// this is pointless
def add (i:Int) (j:Int) = i + j
// unless you need to curry it:
add (3) _
Pair reviews are an excellent means to create good quality code while allowing all team members to help each-other evolve.