Code folding--a solution looking for a problem.

Years ago, when I was programming in GFA Basic on my untrusty old Atari ST (GFA Basic was one of the 'modern" BASICs that *gasp* didn't use line numbers, and seemed more like Pascal), I used to love the editor's code folding ability. Sometimes my procedural programs would get very large, so code folding was a great way to hide away the method bodies and just see a program as a series of high- level "DoThis, DoThat" statements. I'd never seen anything quite like it, and haven't seen the same ability since, until in recent IDE releases for both Java and .Net. The thing is, looking at code folding now, I find it annoying at best. So, naturally, I avoid it. Why the change of heart?

Code folding back in the Atari ST/GFA Basic days was a godsend because BASIC didn't have even a hint of any object-oriented constructs. So I couldn't break code into different classes, encapsulate away the details and just operate on the interfaces. Code folding allowed me to break the code down in a different way, so that I could see the wood for the trees.

What I only realised afterwards was that code folding was encouraging me to write bigger and bigger methods, and not bother to break them up into smaller bite-sized methods. The result was that I too often ended up with "write-once-maintain-never" programs with big monolithic methods. Code folding has begun to reappear in modern IDEs--Visual Studio, .Net, Eclipse, and now NetBeans 3.6. This is odd, because the problems that code folding originally addressed have since been eradicated in other, much neater, less transient ways--namely, object-oriented design.

If you're staring at your program and can't see the wood for the trees, code folding is the wrong answer. The answer is to structure your program better; encapsulate the details into different classes, use interfaces, small methods, and so on. The other thing about code folding is that you end up wasting a lot of time folding methods, unfolding them, when this isn't really getting you anywhere. It feels like you're doing work because you're actively clicking away; but you're not actually making any progress. It's like trying to rearrange the contents of a cupboard by constantly opening and closing the cupboard doors.

So if code folding can promote bad coding habits (even at a subconscious level), should it be included? It's a bit like reinstating the goto statement. Plenty of people love "goto" and insist that it never made them write badly structured code, but still....?..

One area where code folding is useful is in hiding Javadoc. Whether you're writing an API that needs pages of Javadoc above each class and method, or using XDoclet which makes heavy use of Javadoc tags, it can be useful to just hide all this stuff away.

Another area is, of course, when looking at someone else's code. If there's a bad coder on your team, you might want to use code folding to cut their big monolithic classes down to size while trying to work out what the hell the code is doing. Thinking long-term though, this is propagating the problem. If you're working in a team it might become easier to just fold their code away (sweep it under the carpet) than to tackle the issue head-on, i.e. that someone sitting next to you is putting badly written code into the project. So the problem propagates because there's a "quick & easy" short-term fix. A hack, even.!

Technote

Null values in Database Systems

The nullability of a column determines if the rows in the table can contain a null value for that column. A null value, or NULL, is not the same as zero (0), blank, or a zero-length character string such as...."; NULL means that no entry has been made.

A value of NULL indicates the value is unknown. A value of NULL is different from an empty or zero value. No two null values are equal. Comparisons between two null values, or between a NULL and any other value, return unknown because the value of each NULL is unknown. In general, avoid permitting null values because they incur more complexity in queries and updates and because there are other column options, such as PRIMARY KEY constraints, that cannot be used with nullable columns. If it is possible that null values may be stored in your data, it is a good idea to create queries and data-modification statements that either eliminate NULLs or transform NULLs into some other value (if you do not want null values appearing in your data).

If a row is inserted but no value is included for a column that allows null values, the database engine supplies the value NULL (unless a DEFAULT definition or object exists). A column defined with the keyword NULL also accepts an explicit entry of NULL from the user, no matter what data type it is, or if it has a default associated with it. The value NULL should not be placed within quotation marks because it will be interpreted as the character string 'NULL', rather than the null value.

Specifying a column as not permitting null values can help maintain data integrity by ensuring that a column in a row always contains data. If null values are not allowed, the user entering data in the table must enter a value in the column or the table row cannot be accepted into the database. Note: Columns defined with a PRIMARY KEY constraint or IDENTITY property cannot allow null values.