Scala Style GuideOn this page you can find a list of common issues that we detected while looking at some submissions. Some of the style issues can be detected by the automated style checker that we also use for the grading process. The style checker, which is based on Scalastyle, can be executed locally in sbt by running the Common Issues#1 Avoid Casts and Type TestsNever use #2 IndentationMake sure your code is properly indented, it becomes a lot more readable. This might seem trivial and not very relevant for our exercises, but imagine yourself in the future being part of a team, working on the same files with other coders: it is very important that everybody respects the style rules to keep the code healthy. If your editor does not do indentation the way you would like it to have, you should find out how to change its settings. In Scala, the standard is to indent using 2 spaces (no tabs). #3 Line Length and WhitespaceMake sure the lines are not too long, otherwise your code is very hard to read. Instead of writing very long lines, introduce some local value bindings. Using whitespace uniformly makes your code more readable. Example (long line, missing spaces):
Better:
Even better (see #4 and #6 below):
#4 Use local Values to simplify complex ExpressionsWhen writing code in functional style, methods are often implemented as a combination of function calls. If such a combined expression grows too big, the code might become hard to understand. In such cases it is better to store some arguments in a local value before passing them to the function (see #3 above). Make sure that the local value has a meaningful name (see #5 below)! #5 Choose meaningful Names for Methods and ValuesThe names of methods, fields and values should be carefully chosen so that the source code is easy to understand. A method name should make it clear what the method does. No, A few improvable examples:
#6 Common SubexpressionsYou should avoid unnecessary invocations of computation-intensive methods. For example
invokes the
This becomes even more important if the function is invoked recursively: in this case the method is not only invoked multiple times, but an exponential number of times. #7 Don’t Copy-Paste Code!Copy-pasting code is always a warning sign for bad style! There are many disadvantages:
You should factor out common parts into separate methods instead of copying code around. Example (see also #3 above for another example):
This code is better written as follows:
#8 Scala doesn’t require SemicolonsSemicolons in Scala are only required when writing multiple statements on the same line. Writing unnecessary semicolons should be avoided, for example:
#9 Don’t submit Code with “print” StatementsYou should clean up your code and remove all #10 Avoid using ReturnIn Scala, you often don’t need to use explicit
the #11 Avoid mutable local VariablesSince this is a course on functional programming, we want you to get used to writing code in a purely functional style, without using side-effecting operations. You can often rewrite code that uses mutable local variables to code with helper functions that take accumulators. Instead of:
prefer:
#12 Eliminate redundant “If” ExpressionsInstead of
you can simply write
(Similarly for the negaitve case). |