Stef,
My current working theory is that the command pattern is indeed good practice; it also has a way of exacting a price for the flexibility.
Objects as functions are useful. I do a fair amount of that in gathering data from/about various algorithms. The objects can (by inheritance) share details of what to record (with overrides where needed) and then do their own thing on what/how to compute. Add a #subclassResponsibility method for the algorithm's name/label, and the result is fairly nice.
FWIW, I sometimes ask myself why I "bothered" to use command (as I said, it is powerful and trouble all at the same time), but I don't recall regret over objects as functions.
Find bug, write failing test, fix bug with help of new test, in that order; +10.
Short methods - not always!! :) I am reminded of the first time I *enrolled* in a numerical analysis class. Details below for those who have nothing better to do. During that one lecture I attended, he said many things of interest. He talked about generic programming, using equations of lines (Ax+By=C always works, slope-intercept can become indeterminate). He didn't care what language we chose to use for exercises, because (without a hint of arrogance about it) "I will be able to READ (his emphasis) anything in common use." There was more (not bad for a first day of an undergraduate class). The relevant point was his description of structured programming as an alternative to goto instructions. But he said something that was a new thought to me at the time: the problem was not the goto, it was the label, which invites jumps from anywhere.
My point? Short methods come at the cost of many little methods. Each of those "helper" methods is what Dr. X would see as a label. Think about it. Please do not suggest that we enforce private methods in Smalltalk, because the code still reads the same way, and all it really does is force people to copy methods or create forwarding methods to be able to call what they want, making more entry points - IMHO at least.
I am *not* saying that we should have a minimum line length for methods, but there are indeed times when it helps to put an entire thought in one place. If it helps any, I usually encounter this in methods that fork processes. By the time the process gets a loop started, has an #ensure: block to clean up after itself, has a critical section or two, etc., it's not what one would call short, but IMHO, it is one "phrase" that is best seen as a whole.
Bill
So what's all this about enrolling for a class I didn't take? My undergraduate advisor was an interesting guy. One of the more colorful instructions he gave me was to try to get ahead of things by taking numerical analysis as taught by the computer science department; scheduling details meant that I would get the course almost a year earlier than would have otherwise been possible. One caveat: I had clear instructions that if (let's call him Dr. X) was assigned to teach it, leave immediately, drop the course and add (I forget what) in its place.
You already know what happened: Dr. X walked in the room. Not wanting to walk out in the middle of his lecture, I stuck around. After about 20 minutes, I really wanted to take the class, which is why I tried to talk my advisor into letting me do so, but he was emphatic that Dr. X was a first class nut job (some US slang) and that I would end up being just one more bright student who would come back screaming - he had tried several times earlier, always with the same results. With that, I followed his instructions and took numerical analysis in turn.
________________________________________
From:
[hidden email] [
[hidden email]] on behalf of Stéphane Ducasse [
[hidden email]]
Sent: Saturday, December 24, 2011 9:51 AM
To:
[hidden email]
Subject: Re: [Pharo-project] Good practicces! Looking for examples
On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote:
> Not sure what you mean with good coding practice, but here my contrib:
>
> - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser)
> - symbol polymorphic to block and other object-as-function
Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL.
> - writing test before fixing code
> - having short methods
indeed
Here is what I started to write.
Locked
GoodPractices.pdf (136K)