The Software Devotional

Visual Basic 10 Feature - No More Line Continuation Characters (Mostly)

It seems like just yesterday that I was writing my post about the new features in Visual Basic 9. Alas, one of my favorite features of VB9 is extension methods, but I have not been able to use them so much in my day job.

With the release of Visual Studio 2010, Visual Basic 10 will also receive some enhancements. The VB Team announced that VB10's new Implicit Line Continuation will mean that most line continuation characters that were required in the past will become optional. Because VB the carriage return is used as both a line termination character for the Visual Basic compiler and as a line termination character in the code files, it meant that we were not free to organize our code to help make it more readable. Underscores were required to inform the compiler that the current line of code continues on the next line of text. C# handles line continuation without any trouble because it uses a line termination character (the semicolon) that doesn't get confused with the line termination character used to organize code visually (the carriage return).

This is not among the biggest features in VB10. By itself, I don't think this is going to improve readability all that much (as others have said) because the underscores just don't get in the way of reading the code. It will not save VB developers much time either. Underscores will still be necessary in a few circumstances, as described here, but we should see their use go down dramatically.

Maybe getting rid of the underscores will help with readability if it encourages developers to add artificial line breaks where they are helpful for improving readability. We've all seen the ungainly parameter list in a method declaration or a LINQ query that should have been put on 6 lines instead of 2. Not requiring underscores for line continuation might help some developers who eschewed the use of line continuation underscores.

It might also give C# guys one less reason to make fun of VB;

Zen and the Art of Loose Coupling

The volume of responses to my previous article about loose coupling was crazy. It wasn't just the volume - the responses were all over the place. Some of the themes of the comments really surprised me. Some readers vehemently agreed with me, other suggested that loose coupling isn't as big a deal as I made it out to be, and others suggested that there were other areas where I should have focused my attention.

By far, the heaviest volume of responses came from readers pointing out that too much loose coupling is a really bad thing as well. I don't disagree with this point - I even made this point in my post. However, as I replied to some of the authors, I WOULD LOVE TO BE STRUGGLING WITH TOO MUCH LOOSE COUPLING instead of being crippled by too little loose coupling. Making code more tightly coupled is ALWAYS, ALWAYS, ALWAYS easier than modifying tightly coupled code to be more loosely coupled. Besides, I just don't see nearly the incidence of overly loosely coupled code - it just isn't out there to the same degree as tightly coupled code. Not only that, but it just isn't as painful an experience to deal with.

It's an odd thing - my previous post about unit testing has been a big source of short term contract jobs for me. In this capacity, I have been called upon to help with all sorts of unit testing projects from helping to get unit testing kicked off for a project, help write unit tests, and just helping out with understanding how best to use unit tests to increase software quality. Many of the projects I see are nearly untestable, unstable, and difficult to change because of the high likelihood of breaking the project. I see people that are afraid to make changes to this sort of code, which makes it difficult to make needed changes to these projects. In the unit testing article mentioned above, I made the point that a homing beacon for poorly written software, especially tightly coupled software, is that it is difficult to unit test. Count on it.

Let me say it again: like everything else, loose coupling is a balancing act. A good architect will find his Zen for loose coupling and can be a good guide. In many cases, knowing how and when to loosely couple your software will be a mostly intuitive process for someone with years of experience. However, casting error on the side of more loose coupling than you might need will give you a more maintainable and easily tested system than by leaning toward more tight coupling.

Before moving on, I have to admit that I haven't given props to the contribution of cohesion in the role of maintainable software. I'm not going to try to explain it better or more concisely than the cohesion wiki: "cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are." I have more to say about the role of cohesion in quality, but I will save that for another post.

Ideally, we will find a balance between the two extremes (loose coupling and tight coupling), but I'll take software that is too loosely coupled over software that is too tightly coupled - every time.

Resources:

• If you want a more elaborate analysis of cohesion, study the sample chapter from the book The Practical Guide to Structured Systems Design. The chapter does a good job illustrating the differences between the various forms of cohesion.
• Also, the book mentioned above, The Practical Guide to Structured Systems Design, is a great resource for architects looking to understand how to build maintainable software. It leans heavily toward an academic view of software (that's not all bad), and is very long-winded in parts.
• WWMFD? Martin Fowler is always a good source for software-related thoughts. He published an article way back in a 2001 issue of IEEE Software titled "Reducing Coupling". When in doubt, ask yourself What Would Martin Fowler Do?
• By "maintainable software" (I used this nebulous term above), I mean software that is relatively easy to understand, troubleshoot, modify, extend, and test. I include this definition here to direct you to a post by Jeremy Miller where he points out several qualities that make software difficult to work with. His post is well worth your time to read.

devLink 2009

Tennessee developers: registration opened on April 1 for devLink 2009. devLink is a software development conference held in Nashville every year - this year it is scheduled for Thursday, August 13 through Saturday, August 15 and will be held  at the David Lipscomb University campus. Like the big national conferences, devLink provides great session content by great speakers. But unlike the big national conferences, devLink limits attendance (this year to 800 attendees) and its non-procrastinator price is only $75 (goes up to $100 after April 15). Register now because it sells out every year.

devlink is organized by John Kellar: speaker, developer, blogger, and nice guy.

devLink is one of a growing number of "local" conferences being organized all over the country. In general, they are on similar footing as VSLive, DevConnections, and the SD conferences in terms of content, but lack the big-budget venue and marketing blitz. This appeals greatly to me because I dislike the travel expenses of getting to the conferences and because many of the national conferences slant session content toward the material being pushed by the big marketing departments of Microsoft, Oracle and the like. The "local" conferences that come to mind (without Googling) are devLink (Nashville, TN), CodeStock (Knoxville, TN), and CodeMash (Sandusky, OH). Check them out and attend the one that's most convenient to you.

If you know of any that I've missed, please let me know by posting here or emailing me.