The first programming language I learned was Pascal. I was in my math class in secondary school, and my teacher told us about a programming competition that was held every year between schools. At that point, I everything I knew about programming was a pure construct of my imagination. I knew that you were suppose to type something into a machine and it would do things. But I was into computer hardware at the time, so I figured why not. To be honest, I don’t remember much about the language, or those days for that matter. But I do recall trying to grasp the little quirks about the language.
Fast forward to today, it’s been almost 10 years, and I’m still learning new languages and new things about programming languages. I’ve been learning and using Scala for my daily work, and recently I read the Scala Language Style Guide.
While I had read style guides from other languages before, I had always gone to them with the intent of understanding the code style. But reading the Scala Style Guide, it felt more to me as a coding guide. It had many prescriptions on not just code styling, but also when to use specific language features and what they would convey to the reader.
For instance, in the section about control structures, they describe how for can serve for comprehensions and loops, noting how to use different enclosing brackets to distinguish between these two cases, as well as when it is preferable to use them instead of other language constructs, like chained calls to map.
Another is the function naming and calling convention section. Since Scala supports 0-parameter functions being defined without parentheses, they note that any method with side effects should always have parentheses to differentiate them from purely functional methods. Something was unaware of.
The guide is only a few pages long, and it helped me learn a thing or two about the language. It also made me think about what people are trying to convey when they follow the guide.
Naturally, there can be project or team specific style guides. Consistency across a project or team tends to be of higher priority, so developers can easily understand code to modify it. But having a guide is always a good starting point for anyone writing code that will be read by anyone else. Perhaps even themselves.