View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Writing Idiomatic Code - Will Farrington

Writing Idiomatic Code


Writing idiomatic code is by far the most helpful thing you can do for yourself in this course. Doing so yields many benefits and will significantly decrease the number of roadblocks you hit along the way to completing your project. But before we discuss the results of writing idiomatic code, I first need to explain what it means.

There are two primary divisions of idiomatic code: coding style and the “$LANGUAGE (in this case, Smalltalk) way”.

1. Coding Style: Some languages detail in their specs what style the code should take on (or at least parts of it), while there are others that simply leave it up to the programmer to decide. Since Smalltalk doesn’t have a “blessed” code-style (unlike, say, Python’s PEP8 — a technical document detailing the official way to layout your Python code), the next best thing you can do is fall back on general convention: layout your Smalltalk code the same way others layout theirs. Failing that, at least keep your own project consistent internally. Perhaps the most pervasive and annoying example of internal inconsistencies in projects is intermixing tabs and spaces. While this doesn't itself seem like an immediate problem since the Smalltalk VM's compiler will work with both just fine, keep in mind that different systems and editors render tabs differently, so code with tabs and spaces intermixed can appear severely misaligned, so just use one or the other. Other such examples might include if someone is using a line-break after the opening of a code block and someone else isn’t, you end up with code that is inconsistent when reading it. These and more should all be considered very significant problems given that programming languages are designed first and foremost for people to read; not computers. It’d be like reading a novel where the author suddenly jumps back and forth between different dialects of the same language: incredibly frustrating. By keeping your Smalltalk style consistent (at the very least internally if not in-line with other Smalltalk code you’ve seen) you’re going to make working on your project a much less tedious process.

This is Bad:

myMethod
    "indentation using spaces here"
    someCollection do: [ :each | each printString ].
    ^ nil.

myOtherMethod
	"indentation using tabs here"
	someCollection do: [ :each |
		each asNumber.
	]. "inconsistent newline usage for the code block"
	^nil. "and no space after the return operator"


This is Good (ie. consistent):

myMethod
	"indentation using tabs here"
	someCollection do: [ :each | each printString ].
	^ nil.

myOtherMethod
	"indentation using tabs here"
	someCollection do: [ :each | each asNumber ].
	^ nil.


2. The Smalltalk Way: The other part of writing idiomatic code is what I like to refer to as the “$LANGUAGE way”. What I mean by that is simply this: there is a logical way to write certain kinds of statements in the language you’re using (again, in this case Smalltalk) that makes the most sense. Other languages also have their own internal idioms for such things, and in fact, Python’s design philosophy (PEP20 — the "Zen of Python") contains “There should be one– and preferably only one –obvious way to do it.” While Smalltalk doesn’t quite embrace the idea with the ferver that the Python camp does, there is usually a way to write statements that can be described as uniquely “Smalltalk”-ish or at least "more correct". Obviously, if the code works, it is technically correct in the sense that it achieves the desired results; however, like every other form of writing, there is a significant difference between getting across your point and doing it in the best way possible. Like authors, choosing the right "words" to say things should be a very stringent process for programmers. If the language you're working with — whether it be a natural language or a programming language — has some succinct and meaningful way of expressing a concept, you should do it that way. The best example I can think of is when people try to write C- or Java-like for-loops in Smalltalk. While such constructs are common and idiomatic in those languages, they aren’t in Smalltalk and Smalltalk has its own language constructs which allow the programmer to achieve the same results through a different approach. By writing your Smalltalk code in the “Smalltalk way” you will save yourself much frustration; it’s one of those “When in Rome...” sort of things.

Some C code in Smalltalk:

member item: anObject in: aCollection
	1 to: (aCollection size) do: [ :i | ( (aCollection at: i) = anObject) ifTrue: [ ^ true ] ].
	^ false.


Now, the "Smalltalk Way" for the same thing:

member item: anObject in: aCollection
	^ (aCollection includes: anObject).


As you can see, writing idiomatic code leads to wonderful results: clean, elegantly-formatted, consistent code that is a pleasure to work on. So long as you write idiomatic code, you won’t be “fighting” Smalltalk throughout your project. You’ll also learn new ways to think about approaching certain problems as from Smalltalk’s perspective, which will most certainly help you grow as a developer. And really, this is a lesson that extends beyond Smalltalk and into any course where you find yourself using new languages and/or paradigms for problems. Finally, Smalltalk style is a metric for many of the milestones in this course and writing idiomatic code is key to getting points for good Smalltalk style.

Links to this Page