On alt.sex.smalltalk last night, someone had asked how to parse an IP address out of a string (129.9.81.13). Some solutions had been posted, and I thought they were baroque, checking syntax and such.

I thought for maybe 30 seconds: "Parse integers from a stream. Terminate on non-digit. Garbage in stream is error."

Opened Dolphin, created a class with four instance variables. Wrote a nextInteger method on ReadStream:

  nextInteger
    int := 0.
    [self atEnd not and: [self peek isDigit]] whileTrue:
      [int := int * 10 + self next digitValue].
    ^int
Wrote a fromStream: method that read an integer, checked the stream for containing a dot, another integer, another dot, another integer, another dot, another integer, end of stream. Created the object, including a validity instance variable (added) to say whether the parse looked good.

Wrote a UnitTest comparing an IPAddress parsed from a string to one made with the Constructor Method. Fixed the bug in checking for a dot to consume the dot if it was there. Object worked.

Wanted another test to check that I only accepted valid values. It didn't work: IPAddresses couldn't say whether they were valid. Added an isValue method to answer the validity variable, and added a checkValues method to see if the individual values were ok (anding this result with the validity variable).

Error test ran. Took maybe a half hour.

Where was the DesignBeforeCoding? It was the few seconds it took me to think of pulling an integer off the stream and checking the next character for syntax. The rest, creation of the object, creation of the test, naming the methods, was all rote and standard method creation.

Any more design would have been wasted, or so it seems to me.

-- RonJeffries

''where was the DesignBeforeCoding?''

>>

I thought for maybe 30 seconds: "Parse integers from a stream. Terminate on non-digit. Garbage in stream is error."

Sounds like you were visualizing something like a small finite state machine to me. I think you did some kind of analysis/design before code. The fact you didn't formalize it or write it down doesn't necessarily mean you didn't do any design. Experienced/competent people can do this, but I don't think I'd encourage novices to emulate this. Novices actually need to do a bit more formal design - to improve their skills as much as to deliver the goods.
----
I didn't say I didn't do any design, I said it was in those 30 seconds.

I didn't say anything about novices, but what evidence is there that novices need to do more design? Could it be that a really good way to learn to design is to build the design and experience how it goes? If so, novices would do well to spend time building the first thing that comes into their head and then listen to what the experience teaches them.

Another good way to learn about design is to experience good design. For more programmers than might admit it, that's not likely to be found in their heads. Patterns reading, and probably more important, partnering with good designers: those might help more than just thinking. -- RonJeffries

''but what evidence is there that novices need to do more design?''

- From personal experience, it's usually when somebody turns up at your office who wants a quick introduction to java. They want to turn out code but can't be bothered with "this OO stuff" as they put it...

''good way to learn about design is to experience good design...''

- I agree wholeheartedly with this. If only people would take OOA/OOD, patterns and architectures more seriously.

Is there any point in this "thing" besides to brag?

----

Did you know that 10.1 is a valid IP address, and so are 10, 10.0.1, and 192.11042817? Try it out with e.g. 'ping'. Once you get used to this, it's no longer fun when using programs that have just rolled their own dotted-''quad'' parsers. (Not certain whether this is standard or just the way Unix C libraries are implemented!)