HMK's Spurious Thoughts Biased / Nicht immer ausgewogen

Jeff Atwood on When Understanding means Rewriting:

“It’s not that developers want to rewrite everything; it’s that very few developers are smart enough to understand code without rewriting it. And as much as I believe in the virtue of reading code, I’m convinced that the only way to get better at writing code is to write code. Lots of it. Good, bad, and everything in between. Nobody wants developers to reinvent the wheel (again), but reading about how a wheel works is a poor substitute for the experience of driving around on a few wheels of your own creation.”

When I try to understand a given piece code (most embarrassing, my own code written a few months ago), reading the code doesn’t cut it. Instead I try to nibble around on the edges, working from the inside out:
* Looks like the one who wrote the code was short on vowels & consonants for variables – Let’s try to change that – Ah, it still compiles. Cool.
* There are these two lines of code I understand – How about making that a method
* Looks like there’s a comment describing what’s done – Maybe I should try to extract a method
* There’s a certain piece of code used over and over again, maybe I can try to extract that?
* Is this method called from other places too? What do these other places feed in there as parameters?
* There’s this weird global (singleton) there, why is it needed? Let’s change its name. Ah, the compiler tells me where it’s used elsewhere in the system
* Stepping through the code in the debugger, I get a picture of the state of variables
* …
With every tiny step, I gain understanding. Little by little. After understanding this one method, I’m in better shape to understand the next one – Or even the object the method belongs to. Now I apply similar tiny baby steps to classes.
My suggestion is to refactor in order to understand the code instead of rewriting it.
Yup, backing up these refactorings with unit tests is a great idea – but I can still back out from fiddling around with the code without the tests, start the refactorings from scratch, with unit tests – but with some increased knowledge about the system.

Chris Hanson notes that some of Niklaus Wirth’s books are available online (for free).
If you want to read one (very approachable) book on compiler construction, read Compiler Construction by Niklaus Wirth. Excellent stuff.

Here’s some code from the rather interesting blog “Extreme Programming – Simulating an XP project“:
public string SaveToXml()
{
XmlDocument document = new XmlDocument();
//Create a root node called task
XmlElement rootNode = document.CreateElement(“Task”);
document.AppendChild(rootNode);
//If the name exists, store this information
if (this.Attributes.Contains(“Name”))
{
//Append the name information as an attribute
XmlAttribute nameAttribute = document.CreateAttribute(“Name”);
nameAttribute.InnerText = this.Attributes[“Name”].ToString();
rootNode.Attributes.Append(nameAttribute);
}
//If the creation date exists, store this information
if (this.Attributes.Contains(“CreationDate”))
{
//Append the creation date information as an attribute
XmlAttribute creationDateAttribute = document.CreateAttribute(“CreationDate”);
creationDateAttribute.InnerText = this.Attributes[“CreationDate”].ToString();
rootNode.Attributes.Append(creationDateAttribute);
}
//If the due date exists, store this information
if (this.Attributes.Contains(“DueDate”))
{
//Append the due date information as an attribute
XmlAttribute dueDateAttribute = document.CreateAttribute(“DueDate”);
dueDateAttribute.InnerText = this.Attributes[“DueDate”].ToString();
rootNode.Attributes.Append(dueDateAttribute);
}
}
It’s a rather typical example for a “Comment smell”:
* The comments are not needed because the code communicates very clearly what is done (even to someone like me who’s not an XML-Guru at all)
* If the comments are not needed, we should get rid of them because they pollute the code plus they will get out of sync with the code in the long term (Can you say “Cut/Copy/Paste”? 🙂
Plus, the comments are hints on potential refactorings like extract method.

SugarCRM.
Interesting. To my (limited knowledge), the closest thing to an open source, vertical business application.

Ivan on Programming in the small – removing duplication:

“Look out for duplication – it might be telling you something”

Interesting observation: Removing duplication isn’t about removing redundancy only, it’s about migrating towards a better, more object-oriented design, too.