In falling in love with a programming language, one of the qualities most people look for is the level of elegance that can be achieved within the language. Few things are more satisfying to a programmer than solving the problem with beautiful, elegant code.
Elegance and conciseness are closely related. It would be hard to call a 500 line method elegant - even if it was creating world peace; surely world peace can be implemented in 5 to 10 lines. In the same way, a very short method that does something useful is more likely to be elegant code. Concise is nice.
The support provided by the language/libraries for writing concise code is a strong factor in choosing that language. Some languages don’t exactly go out of their way to help you write concise code, some have a mixture of facilities for writing concise code and others attempt to be permanently concise. It’s all about finding the right balance that results in efficient and maintainable code.
Being concise is important because it’s a good step forward in writing easily understandable code. A real example may help illustrate the point.
1: public static int Max(int[] numbers)
2: {
3: int currentMaximum = 0;
4:
5: foreach (var number in numbers)
6: {
7: if (number > currentMaximum)
8: {
9: currentMaximum = number;
10: }
11: }
12:
13: return currentMaximum;
14: }
While the above C# example isn’t particularly difficult to read or understand, there is a lot going on for such a simple method. The concept of the method is very basic, yet I had to take my mind off the task at hand to write what is essentially meta-code. Line 3 has nothing to do with my overall goal, but is necessary due to the details of the algorithm.
When the language/platform provides more facilities for conciseness, it helps you abstract away from some of the meta work that is otherwise needed to implement the usual boilerplate kind of stuff. This argument is made toward the use of conventional C++ in a business application environment for the same reason. Having to deal with memory management, buffer checking and related issues detracts away from the higher level problem you’re trying to solve.
With the introduction of LINQ to the .NET framework, conciseness has been made much easier through various extension methods. These extension methods provide generic operations for generic containers using an elegant syntax. Thus the example from above now becomes:
1: public static int Max(int[] numbers)
Looking at the new version of the Max method, the intention of the code is much clearer because we’ve not had to pollute it with details that aren’t necessary. See if conciseness helps you understand the following examples:
1: double averageCost = monthlyCosts.Average();
3: int totalAdmins = users.Count(c => c.Admin);
5: var addressesOnly = users.Select(c => new { Address = c.Address });
When the logic of the code can be expressed so concisely you don’t get distracted by many moving parts and the intention becomes clearer. You may argue that this entire issue is one that traditional encapsulation is meant to solve – and I would agree. Encapsulation allows you to hide the unnecessary implementation details away so that conversation with the object can happen through a clean interface – but this is only true for code external to the object. Ultimately you still need to write these algorithms, whether it’s encapsulated in some class or not.
Regardless of where you are writing code, if your language captures generic operations and provides an elegant and concise syntax for performing those operations, you will be able to write cleaner and more maintainable code.
The quest to make our code more concise and elegant is nothing new and has been happening since day one. To those only familiar with assembly language, the conciseness provided by the introduction of for loops and if statements was equally compelling. As time goes on, language innovation will allow us to write more and more concise code and focus our attention on the things that matter most.
On a final note, it’s worth mentioning that while writing concise code is generally a good practise, it can also be bad. It is possible to be too concise, taking you into the realms of cryptic. As a practitioner of conciseness, it’s your duty to constantly evaluate whether your new elegant code helps or detracts from the overall meaning.