{"id":689,"date":"2011-11-16T13:11:00","date_gmt":"2011-11-16T13:11:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/scala-tutorial-code-blocks-coding-style-closures-scala-documentation-project.html"},"modified":"2012-10-21T20:39:47","modified_gmt":"2012-10-21T20:39:47","slug":"scala-tutorial-code-blocks-coding-style","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/11\/scala-tutorial-code-blocks-coding-style.html","title":{"rendered":"Scala Tutorial – code blocks, coding style, closures, scala documentation project"},"content":{"rendered":"
\n

Preface<\/h2>\n

This is part 12 of tutorials for first-time programmers getting into Scala. Other posts are on this blog, and you can get links to those and other resources on the links page of the Computational Linguistics course<\/a> I\u2019m creating these for. Additionally you can find this and other tutorial series on the JCG Java Tutorials page<\/a>.<\/p>\n

This post isn\u2019t so much a tutorial as a comment on coding style with a few pointers on how code blocks in Scala work. It was instigated by patterns I was noting in my students\u2019 code; namely, that they were packing everything<\/strong> into one-liners with map after map with map after map, etc. These map-over-mapValues-over-map sequences of statements can be almost incomprensible, both for some other person reading the code, and even for the person writing the code. I do admit to a fair amount of guilt in using such sequences of operations in class lectures and even in some of these tutorials. It works well in the REPL and when you have lots of text to explain what is going on around the piece of code in question, but it seems to have given a bad model for writing actual code. Oops!<\/p>\n

So taking a step back, it is important to break operation sequences up a bit, but it isn\u2019t always obvious to beginners how one can do so. Also, some students indicated that they had gotten the impression that one should try to pack everything onto one line if possible, and that breaking things up was somehow less advanced or less Scala-like. This is hardly the case. In fact much to the contrary: it is crucial to use strategies that allow readers of your code to see the logic behind your statements. This isn\u2019t just for others \u2014 you are likely to be a reader of your own code, often months after you originally wrote it, and you want to be kind to your future self.<\/p>\n

A simple example<\/h2>\n

I\u2019m giving an example here. of what you can do to give your code more breathing space. It\u2019s not a very meaningful example, but it serves the purpose without being very complex. We begin by creating a list of all the letters in the alphabet.<\/p>\n

scala> val letters = \"abcdefghijklmnopqrstuvwxyz\".split(\"\").toList.tail\r\nletters: List[java.lang.String] = List(a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z)\r\n\r\n<\/pre>\n
Okay, now here\u2019s our (pointless) task: we want to create a map from every letter (from \u2018a\u2019 to \u2018x\u2019) to a list containing that letter and the two letters that follow it in reverse alphabetical order. (Did I mention this was a pointless task in and of itself?) Here\u2019s a one-liner that can do it.<\/p>\n
scala> letters.zip((1 to 26).toList.sliding(3).toList).toMap.mapValues(_.map(x => letters(x-1)).sorted.reverse)\r\nres0: scala.collection.immutable.Map[java.lang.String,List[java.lang.String]] = Map(e -> List(g, f, e), s -> List(u, t, s), x -> List(z, y, x), n -> List(p, o, n), j -> List(l, k, j), t -> List(v, u, t), u -> List(w, v, u), f -> List(h, g, f), a -> List(c, b, a), m -> List(o, n, m), i -> List(k, j, i), v -> List(x, w, v), q -> List(s, r, q), b -> List(d, c, b), g -> List(i, h, g), l -> List(n, m, l), p -> List(r, q, p), c -> List(e, d, c), h -> List(j, i, h), r -> List(t, s, r), w -> List(y, x, w), k -> List(m, l, k), o -> List(q, p, o), d -> List(f, e, d))\r\n<\/pre>\n
That did it, but that one-liner isn\u2019t clear at all, so we should break things up a bit. Also, what is \u201c_\u201d and what is \u201cx\u201d? (By which I mean, what are they in terms of the logic<\/strong> of the program? We know they are ways of referring to the elements being mapped over, but they don\u2019t help the human reading the code understand what is going on.)<\/p>\n
Let\u2019s start by creating the sliding list of number ranges.<\/p>\n
scala> val ranges = (1 to 26).toList.sliding(3).toList\r\nranges: List[List[Int]] = List(List(1, 2, 3), List(2, 3, 4), List(3, 4, 5), List(4, 5, 6), List(5, 6, 7), List(6, 7, 8), List(7, 8, 9), List(8, 9, 10), List(9, 10, 11), List(10, 11, 12), List(11, 12, 13), List(12, 13, 14), List(13, 14, 15), List(14, 15, 16), List(15, 16, 17), List(16, 17, 18), List(17, 18, 19), List(18, 19, 20), List(19, 20, 21), List(20, 21, 22), List(21, 22, 23), List(22, 23, 24), List(23, 24, 25), List(24, 25, 26))\r\n\r\n<\/pre>\n
It\u2019s quite clear what that is now. (The sliding<\/strong> function is a beautiful thing, especially for natural language processing problems.)<\/p>\n
Next, we zip the letters with the ranges and create a Map<\/strong> from the pairs using toMap<\/strong>. This produces a Map from letters to lists of three numbers. Note that the lengths of the two lists are different: letters<\/em> has 26 elements and ranges<\/em> has 24, which means that the last two elements of letters<\/em> (\u2018y\u2019 and \u2018z\u2019) get dropped in the zipped list.
 
<\/div> <\/div><\/p>\n
scala> val letter2range = letters.zip(ranges).toMap\r\nletter2range: scala.collection.immutable.Map[java.lang.String,List[Int]] = Map(e -> List(5, 6, 7), s -> List(19, 20, 21), x -> List(24, 25, 26), n -> List(14, 15, 16), j -> List(10, 11, 12), t -> List(20, 21, 22), u -> List(21, 22, 23), f -> List(6, 7, 8), a -> List(1, 2, 3), m -> List(13, 14, 15), i -> List(9, 10, 11), v -> List(22, 23, 24), q -> List(17, 18, 19), b -> List(2, 3, 4), g -> List(7, 8, 9), l -> List(12, 13, 14), p -> List(16, 17, 18), c -> List(3, 4, 5), h -> List(8, 9, 10), r -> List(18, 19, 20), w -> List(23, 24, 25), k -> List(11, 12, 13), o -> List(15, 16, 17), d -> List(4, 5, 6))\r\n\r\n<\/pre>\n
Note that we could have broken this into two steps, first creating the zipped list and then calling toMap<\/strong> on it. However, it is perfectly clear what the intent is when one zips two lists (creating a list of pairs) and then uses toMap<\/strong> on it immediately, so this is certainly a case where it makes sense to put multiple operations on a single line.<\/p>\n
At this point we could of course process the letter2range<\/em> Map<\/strong> using a one-liner.<\/p>\n
scala> letter2range.mapValues(_.map(x => letters(x-1)).sorted.reverse)\r\nres1: scala.collection.immutable.Map[java.lang.String,List[java.lang.String]] = Map(e -> List(g, f, e), s -> List(u, t, s), x -> List(z, y, x), n -> List(p, o, n), j -> List(l, k, j), t -> List(v, u, t), u -> List(w, v, u), f -> List(h, g, f), a -> List(c, b, a), m -> List(o, n, m), i -> List(k, j, i), v -> List(x, w, v), q -> List(s, r, q), b -> List(d, c, b), g -> List(i, h, g), l -> List(n, m, l), p -> List(r, q, p), c -> List(e, d, c), h -> List(j, i, h), r -> List(t, s, r), w -> List(y, x, w), k -> List(m, l, k), o -> List(q, p, o), d -> List(f, e, d))\r\n\r\n<\/pre>\n
This is better than what we started with because we at least know what letter2range<\/em> is, but it still isn\u2019t clear what is going on after that. To make this more comprehensible, we can break it up over multiple lines and give more descriptive names to the variables. The following produces the same result as above.<\/p>\n
letter2range.mapValues (\r\n  range => {\r\n    val alphavalues = range.map (number => letters(number-1))\r\n    alphavalues.sorted.reverse\r\n  }\r\n)\r\n\r\n<\/pre>\n
Notice that:<\/p>\n