Scala programming guidelines
Julien Wetterwald
Here is the first part of an upcoming series on Scala programing guidelines. Let me know what you think and feel free to add your own suggestions! I am beta testing them on the Lift community :-)
1. No beastly indentation and alignment.
def something(...) = ... match {
case Something() => ...
case SomethingElse() => ...
case _ => ...
}
def something(...) = // don't be afraid of adding line breaks
... match {
case Something() => ...
case SomethingElse() => ...
case _ => ...
}
2. Be consistent.
... match {
case Something() => ...
case SomethingElse() =>
...
...
}
... match {
case Something() =>
...
case SomethingElse() =>
...
...
}
3. Don't abbreviate, there are many abbreviations for a single word! Which one should the developer use?
val lst = ... val elem = ... val init = ... val col = ... val list = ... val element = ... val initialize = ... val column = ...
4. No unnecessary prefixes.
class Component {
def getName = ...
def setName(...) { ... }
def isValid = ...
def toHTML = ...
}
if (component.isValid) component.toHTML
class Component {
def name = ...
def name_=(...) { ... }
def valid = ...
def html = ... // "to" was obvious
}
if (component.valid) component.html
4. Group class properties in objects to improve properties hierarchy.
class Table {
def getRowColor = ...
def getRowFont = ...
def getColumnColor = ...
def getColumnFont = ...
}
table.getRowColor
class Table {
object row {
def color = ...
def font = ...
}
object column {
def color = ...
def font = ...
}
}
table.row.color
5. Nest classes. A class name should contain one and only one information: the name of the class. Bonus: you can spell check your code!
abstract class Mapped
class MappedString extends Mapped
new MappedString // looks like Hungarian notation!
abstract class Mapped
object Mapped {
class String extends Mapped // don't be afraid of reusing existing class names
}
new Mapped.String
Cheers,
Julien
Matthew Shilts
Ryan Daum
it's great to build some consensus around style in Scala, but it needs
to take place in the right forum and have the input of the language
founders.
(P.s. I agree about having 'set' be explicit; it makes things more
readable. Either that, or do some magic with overloading the assignment
operator with some implicit defs)
Ryan
Julien Wetterwald
> I like everything except the "set" as variable_
following code
class Foo {
private var something: Int = _
def bar_=(i: Int) { something = i }
}
allows you to write
val f = new Foo
f.bar = 3
It is the official "setter syntax" in Scala.
> Please forgive my ignorance.. But, where does that "_" notation come
> from?
Actually, there is an underscore in the method name only because the
following character, "=", is a special character and that all special
characters have to be preceded by an underscore. As you can see, the "_"
is only required in the method definition.
Cheers,
Julien
Julien Wetterwald
> Shouldn't this discussion be taking place on the Scala list? I think
> it's great to build some consensus around style in Scala, but it needs
> to take place in the right forum and have the input of the language
> founders.
i.e. I am following them while developing Lift and wait for some
feedback from other developers and/or users. Having worked with the
Scala team and TAing their advanced programming course, I am sure I will
have their input soon enough :-)
But you are right, when these guidelines will be finished, I will
definitely post them on the Scala mailing list.
Cheers,
Julien
David Pollak
Thanks for forwarding these suggestions to the lift list.
I'm going to do my best to implement these suggestions in lift (and you're encouraged to fix the lift code when you see more compliant ways to code lift and examples.)
It'd be RealNice(tm) if the various Scala editor modes better supported indentation (especially for match/case.)
Anyway, please keep on "beta testing" guidelines and other suggestions.
Thanks,
David
Ryan Daum
Eclipse modes were made to follow the indentation/alignment suggestions
given.
Off the top of my head, here's some questions that could be addressed
1. when to use "for" expressions, and when to use map on Iteratable?
2. when to use abstract classes versus traits
3. when to use case vs not-case classes (other than obvious pattern
matching uses)
4. val vs var
5. when is operator overloading appropriate
6. when are implicit defs appropriate?
7. when to use type members versus generic type parameters
8. brevity/functional style an explanation on the benefits, blocks like
this:
def z = {
val x = someValue
val y = x * someOtherValue
y
}
vs
def z = someValue * someOtherValue
9. when in general to use pattern matching vs. method dispatch
10. pattern matching vs. i.e. visitor pattern
11. various other patterns that are meaningful in java world but made
somewhat obsolete by scala language facilities
Ryan
Ryan Daum
* Package naming conventions different from Java because a single
package can contain multiple classes.. what's the right way? Plural,
singular? (org.foo.Expressions or org.foo.Expression); What should it
refer to?
* What belongs in a package together?
Ryan
Julien Wetterwald
These are really good questions, thank you very much. I will definitely
use them as a starting point for the second part of my guidelines.
Cheers,
Julien