The Three Ways to Work with Code

Obviously you read code more often than you write it. Nothing new here. This fact is brought up often when the need for clean code is discussed. Or when the merits of different programming languages are weighed.

I think this two fold distinction is not sufficient. You write code. That’s fine. But when reading code, there are actually two different kinds of reading. Lets start with an example:

val string = "Hello World"
string should startWith ("Hello")

Even if you didn’t follow my articles about ScalaTest you can understand what this line of code is doing. In this sense reading this line of code is extremely easy. I call this ‘skimming’

But what if this line of code is not doing what you expected? Then you need to really understand the code. Then you want to understand what is going on. In the Scala example above you might consider the following options: Is startWith(“Hello”) a parameter to should? Or is “Hello” an argument passed to the result you get after passing startWith to should? What is should anyway? A method? An object? A function? An instance with apply method?

As you can see what was realy easy to skim now gets quite challenging to ‘understand’.

The same can be the case for libraries. Consider Hibernate. If you have setup Hibernate, CRUD operations on an entity are really easy to write and understand. But once you get one of the dreaded Hibernate exceptions (LazyInitializationException, NonUniqueObjectException,…) you want to really understand what is going on. And at that point many people realize they have no idea what is actually happening when they call session.update or just the getter of an Hibernate Proxy.

Obviously you want all three kinds of handling code to be as easy as possible, and writing might be the least important, because we read more code then we write. But how important is the ability to skim versus understanding?

With anything you use in an application you will do a lot of skimming. That’s why DSLs like the ScalaTest example above are such a great tool.

I suspect if you do complex things with a library or a language, understanding will always be hard. But in some cases it gets extra hard because non standard tricks are used. In Java a typical case of trick is Reflection and Byte Code Manipulation. Many of the more powerful libraries use it to work around the limitations of ‘normal’ Java. The result is code that is easy to skim but for many people next to impossible to understand. Examples are Mockito or Hibernate.

So when evaluating a library or writing one you might consider how much magic it is using.

The other way to limit the problem with ‘understanding’ code is to make it unnecessary. I think Hibernate is an example where this failed. You have tons of places where you have to understand pretty exactly what Hibernate is doing in order to use it correctly.

Java itself is an example where this works pretty good. In many, many projects nobody has to actually understand how the JVM works. It just works. Only in rare cases you have to dive into the details of the garbage collector or the memory model.

The key here is a clean non leaky abstraction. If you have that it doesn’t matter what kind of magic you use to make it happen. But if your abstraction is leaky, parts of the magic you use inside will leak out with the risk of turning your project into something that acts like it is bewitched.

Reference: The Three Ways to Work with Code from our JCG partner Jens Schauder at the Schauderhaft Blog.

Related Articles :
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply

3 × six =

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books