BT

Communicating Intent through Idiom and Paradigm Selection

| by Sadek Drobi Follow 0 Followers on Feb 15, 2008. Estimated reading time: 2 minutes |

Making code more readable and more explicit? Reg Braithwaite believes that correctly choosing programming idioms can be instrumental for achieving that goal. He stresses that there are often several ways to get to the desired outcome and the choice should not be random. One should prefer the tool that signals in a most obvious way the intent of the piece of code that is being built. Syntax choices, for instance, can bear useful information about code’s intent:

Consider blocks in Ruby. Some people use do … end when the block needs multiple lines and { … } when it fits on one line. A popular (AFAIK) and superior idea is to use do..end and {…} to disambiguate between blocks that are executed chiefly for their side effects and blocks that are executed for their return values:

foo.map { |x|
# I care about the result
}
foo.each do |x|
# I care about the side effects
end

The computer doesn’t care, of course, but it signals an extra piece of information, the fact that you are chiefly interested in side effects in one case and chiefly interested in the result in another case.

Braithwaite believes that this approach is not limited to syntax idioms but can scale up to paradigms. In some languages, e.g. Ruby, “there are several entirely different philosophies the language supports.” This can be used as a means to declare intent by borrowing idioms from paradigms that correspond the best to what one is trying to achieve.

By making functional things look functional, you clearly signal that you are performing a calculation strictly for the result. Using imperative syntax like for and while should be reserved for the times you need to mutate variables or cause other side effects. […] Likewise, OO is a great paradigm—when you are modelling entities in the real world or when you need long-term persistent state. Languages like Ruby force you to use objects behind the scenes, your code shouldn’t look OO unless you are trying to signal your colleagues that there are entities involved.

Even though it is obvious that, sometimes, the choice of paradigm may be imposed by performance requirements, using this kind of conventions, when possible, allows providing additional information to programmers thus making code more readable and more expressive.

Some argue that using undocumented and unvalidated conventions would only result in more confusion. Reg argues, however, that any project involves programming conventions of some kind, e.g “using Bang! method names to indicate state changes (sort vs. sort!)”, and that nothing prevents teams from documenting established conventions, if necessary.

What do you think about using idioms as signals and means to declare intent?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Makes sense but... by Matthias K.

... I think that if you already bother using specific programming idioms to make your code more readable, maybe that's an indicator that it is lacking in more obvious ways for increasing readability, such as proper naming of identifiers.

Another problem is that there has to be a shared understanding of what the usage of certain idioms in certain situations actually means to the programmer. This will differ not only with languages, but also with the people who actually read and write the code.

be careful by ding jack

conventions are everywhere, but widely recognized conventions are rare. so, be careful.

makes me think of new syntax by John DeHope

I'd prefer something a little more explicit. If we're going to communicate, why not communicate clearly and specifically? Why rely on subtle clues about our meaning? Why would anyone use 'map' unless they wanted the result set? Why would anyone use 'each' if they wanted the result? I'd prefer to see 'each' have a void return value (I am not a ruby programmer so maybe it already does). That would make it crystal clear. 'map' gives you back a return set, 'each' gives you back void. Nothing spells intent like a void pointer :)

On the subject of functional programming... I wonder if we'll be able to specify read-only-ness at the method and argument level? That would make it really clear when you were being functional and when not. If there was a token of some kind you could attach to a method that said "hey I will not touch the 'this' object's data" and also a token on arguments that said "I will not touch this argument, and I promise not to call any of it's methods that touch it". Now we can program in a functional way without anyone being confused about what we're doing.

I realize I am thread-jacking here. The original post is talking about using existing semantics to convey intent. I am talking about conveying intent with new semantics (and syntax) that enforce that intent. I hope that's okay.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT