A language is a set of standards. One has to follow them in order to avail benefits from the language. In order to maintain these standards, code in Scala has to be written in order to minimize the errors whether they are related with the concepts like redundancy of operations, use of properties of language those not supported by ScalaStyle or ScapeGoat or other checkers.
The standard of code is maintained in order to write a block of code having few lines and perform large operations effectively. In order to follow the effective standard of Scala, we can go through the following conditions and what should be their standard representations,
Matching without null
Sometimes we want to match a value whether it is a string or something that returns a null in case of default case, the code to simply match it is written as,
But in a better way it can be defined as,
Indices of List
In few cases when we want to read the content of many collections at the same time or we say, we want to iterate more than one list at a time and get the element of another list at the same time, we prefer the following code for simplicity,
In a better way to iterate the indices of a list, we can rewrite the above code as,
In Scala, the map is commonly and most frequently used to iterate a collection. But sometimes there can be the following two conditions possible,
- We return some value,
- We return a unit, in case of performing any file content writing operations
In above case map returns a list of string, so it is good to use the it here.
In above case we are not returning any value, so here we should replace map with foreach as below,
Avoid map over match
Sometimes if we are in situation where we have a list defining some values may be defined or undefined (Options). Now to iterate the code is written as below,
Above the names are already being mapped, so we can remove the match there,
While programming in Scala, there are certain conditions where we face the code written in java specially while using any external api’s, whose documentation is written in java. So, java converters provide a better way of transforming these java properties into Scala.
Suppose we have an ArrayList of java utility package as below,
Now to transform we use the java converter as below,
Now in the above code, we transformed the java ArrayList into mutable buffer of scala, Now we can easily change it to a list of scala,
Collections over Conditions
Sometimes we have a number of choices so that a value must match with any of them, at that time the easy approach is to match that element with those choices as below,
Above code wants to verify, which type of drink does the name belong to. Code is simple but not easily understandable and complex to be programmed. The code can be written as below using collection,
Now we defined two groups having their respective drinks. And it is easily understandable.
So there are some practices in scala, so that code can be rewritten in more effective way.
Happy Blogging !!
5 thoughts on “Effective Programming In Scala – Part 1 : Standardizing code in better way6 min read”
Nice article, just a quick contribution, I think the main reason to use map vs foreach is wheter you want to explicitly have side effects, map is used to transform values of a collection while foreach just execute a piece of code that returns nothing, so probably the piece of code in the foreach function will have a side effect.
Yes, nice explanation Macro and foreach is the best whenever the requirement is to execute or perform an action without returning its result to others.
if(alchoholicDrinks.contains(name) || softDrinks.contains(name)) true else false should be replaced by simply alchoholicDrinks.contains(name) || softDrinks.contains(name)
Yeah i know, but due to above comparison as in if-else case, i used the if-else case
map should only be used if you need another collection transformed by your function.
by the way, last rule is more a language independent.
we should be avoiding dealing with indices as much as possible, collections support zip* method for that purpose.
Comments are closed.