Style or formatting is the most ignored practice in all of programming - well, arguably. To me, formatting represents the single most important part of the coding. Formatting has the potential to do the following to the code:
- enhance the understandability of the code
- make the code easier to read
- reduce the amount of time a developer spends deciphering what the author intended
- encourage good programming practices
- speed up the development cycle
- illuminate stinky code, cheats, shortcuts, hacks, you name it
- reduce the learning curve for new developers
- lend a consistent pattern to all methods
- uncover hidden code complexity
One of the problems with style is choosing one that everyone will agree on as the best. Another problem is getting everyone to adopt the style that is chosen. Finally, getting everyone to consistently repeat the style and not do it only some of the time.
With smalltalk, I’ve seen many different styles, usually an amalgamation of several different authors with different styles that achieve different purposes. I’ve only found one style that encompasses a holistic approach to software design and patterns; only one that achieves all of the bullets above and a few benefits I’ve forgotten. That is the one proposed by Kent Beck in his book Smalltalk Best Practice Patterns in Chapter 7. The styles he presents are so common sense, I can hardly believe that not one of the smalltalk distributions have adopted it. With so many smart people, why can they not see the genius in this style guide.
I just don’t understand why style is ignored to the extent that it is. Code is more important than good code unfortunately and I guess that is the main reason why. I can understand each shop wanting to employ a style of their choice, but shouldn’t the baseline formatting be the best that is available. I welcome a debate on which style guide is best. Some will win in small scenarios but nothing that I have seen or read about touches the brilliant guide that Kent Beck put together. I may opt to adjust a few things in his guide, but nothing very big, and nothing I simply “have to have”.
So, what makes a good style guide anyway? I believe that it begins with the phrase, “no exceptions”. In other words, very very consistent. Another measurement is in regard to readability. If the code formatting itself can relate to me the flow of the code, I can read it much better.
Consistent is a bit ambiguous when discussing code styling because one must consider indents, contexts, and other punctuation and syntax. The most consistent will cause all the rules in the style guide to always be true.
Here’s a little example, in Smalltalk, of course:
^1 = 1 ifTrue: [1] ifFalse: [0]
Now, after applying Kent Beck’s style guide:
^1 = 1
ifTrue: [1]
ifFalse: [0]
While the first example is more concise, and I know a bunch of programmers love concise code, the rule is that whenever the receiver is sent a multi-named method, it’s components drop down to the next line.
The readability of the code may not seem much different in this example, but trust me, legacy systems can include some herculean methods and following them is next to impossible without Kent’s formatting. And, that is the point. Using this style guide works for all cases, bar none.
Here’s a slightly more complex example:
[one=1] whileFalse: [one:=self getOneForDate: Date today withId: 3.
one=9 ifTrue: [ self displayNine] ]
I agree, the above method isn’t terribly good, but its only purpose is to illustrate how styling can improve readability. Here it is again, formatted according to Kent’s style guide:
[one = 1] whileFalse:
[one := self
getOneForDate: Date today
withId: 3.
one = 9 ifTrue: [self displayNine]]
I will talk more about each of the style rules in more detail in subsequent posts. I only wanted to introduce the topic here to get me started.
The second example is far easier to follow and gives us little to decipher. Instead, the code just speaks to us because we expect it in a certain form and it is always in that form. There’s little guessing about how this little bit of code operates, horrible as it is.
Let me add an ifFalse: to that last part and see how it changes:
[one = 1] whileFalse:
[one := self
getOneForDate: Date today
withId: 3.
one = 9
ifTrue: [self displayNine]
ifFalse: [self displayEight]]
In essence, whenever a chunk of code takes up more than one line, it begins on the next line. Multi-named methods constitute more than one line.
So, that’s a start. Styling can reshape the way we view solving problems, it can reshape our thinking so that the language doesn’t entirely exist. Instead, Smalltalk becomes a kind of blur in the background as we design elegant and patterned applications and spend most of our time testing and refactoring.
Brief Summary: Anthony Hopkins plays a biologist who has studied apes for many years. He ends up in a security hospital/jail for folks with mental issues. He is then confronted by Cuba Gooding Jr., a psychologist who implores Hopkins to tell his story.
Reaction: Just watched this movie for the second time over the weekend. I was so moved by the forged relationship between Hopkin’s character and the small clan of apes who had accepted him as one of their own. The movie reaffirmed to me the beauty in all creatures and how we humans continue to ruin our world with consistent disregard for our true place in it.
While we should be the caretakers, we instead take care of only ourselves. We continually find ways to place ourselves in a position of superiority and disregard all the “lesser” life-forms. We find ways to divide ourselves and our world, we forget that we are a product of this world and should hold all things in the deepest respect.
This movie made me want to divorce the human race altogether. Why do we place so much value in inanimate objects (money, cars, houses) and focus so much negative energy on ourselves and each other? Why are we not practicing advancing our world and instead continue to destroy it?
I found many meanings in this film for myself. It touched an inner part of me that had been lying dormant for several years now. I’ve avoided the animal channel because I did not want to face the realities of what is happening with our Polor Bears, our pets, etc… It is truly painful to bear witness to the suffering that we humans inflict on the rest of the animal and plant species. I realize, however, that the pain is a gift and a communication to pay attention and to act in whatever capacity I have available. To contribute what I know and wish for and to assist and aid with reparations.
I highly recommend this film. Who knows, it may touch some part of you as well.
I have programmed in several languages, not as many as most geeks, but enough to know that there are clear advantages and disadvantages depending on what task is at hand. Cobol is easy to learn, english-like, has a fairly simple syntax, and performs very well (on IBM mainframes that is). C is incredibly powerful, has an open and complex syntax, includes more solutions for one problem than you can shake a stick at, and performs very well on all platforms. Pascal is simple and fairly elegant in it’s approach to solving problems - adapts well to beginning program theory & practice. Java is very capable, widely adopted, stable, and comes with more libraries than I think just about any other language. Perl offers a wide array of functional aspects that made the first dynamic web pages possible. Lisp has a flexibility that is unmatched and a built-in invention paradigm (for lack of a better term) that has led to some of the greatest language adaptations borrowed by all the languages - you say Lambda, I say Block, Lambda, Block … 
None of these languages ever really won me over though. Of the list above, I most enjoyed C & Pascal, and I thought that C would be my favorite as I pondered other careers. Then, just on my way out the door, never again to return to the world of programming, I discovered software development. I found a language that was consistent, pure, simple, concise, powerful, elegant, and fast. Yep, you guessed it, I found smalltalk.
Instantly, my world was altered. No longer were bits and bytes important. No longer was syntax important. No longer were performance and memory an all-consuming priority. Instead, I could spend my time providing my customers with software solutions, elegantly crafted, simplistic in their nature, and fully mappable to the english(business) language.
As with any language, developers with no or little regard for styling, best practices, and reusability can make some incredibly stinky code, even in smalltalk. With smalltalk, however, it’s less difficult to refactor code that stinks because the language is built right into the environment. In fact, the environment is built from the language in the first place. The debugger allows for code stepping that is still, to this day, unmatched.
Smalltalk really is an amazing language and will outlast all of the other beasts. This is an interesting prediction considering that the smalltalk following is far less than that of most other popular languages. If you look at the improvements that are being made in other languages (e.g. Groovy for Java), the features that are being added are more smalltalk like. The direction is to move to the better language design and smalltalk had the others beat back in the 80’s, even though Java, C#, and a host of other languages had not yet been invented. Smalltalk was clearly ahead of its time.
This commentary isn’t really an objective view of the language. I haven’t really demonstrated anything. I just wanted to post my love for the language and the fact that all of the other languages have some beauty about them. I hope to provide demonstrable support for the claims I make, sometime down the road.
