#develop (SharpDevelop) is an interesting project I've mentioned here a number of times. It's a "free-as-in-puppies" IDE for C# written in C#. For a while it was barely more than a syntax highlighter that tied your F5 key to a very specific shell command (that would compile and run your code in the .NET runtime), but it's a decent IDE now with code-completion which comes with a reasonable price. That said, if you need to create a GUI, you're still better off plunking down a C note for the C# portion of Visual Studio.NET. But #develop is GPL and getting better all the time... Maybe once Mono's more mature more people will have time to contribute to the #develop project.

Anyhow, I just downloaded #develop version 0.89 and had two comments. The first one's quite quick: I notice that #develop is using OpenOffice file formats for its documentation. I've been using OO a little recently, and it does a fairly good job translating Word docs and a better job of being a word processor. Powerpoint presentations [sic!] and Excel files are opened and edited fairly easily as well, as long as the files don't use many non-standard bells and whistles.

I especially like its autocomplete function, where OO tries to guess what word you're typiing based on the words already in your doc. You hit return to accept the word, or just keep typing. Not nearly as clumsy as it sounds. OO is bound to be available for one of your OS's of choice, so have a look.

Comment two comes from a new document on the #develop Tech Notes pages. There's an article entitled "The fine Art of Commenting [pdf]". I'm a pretty big believer in commenting, which for years I didn't realize was a controversial stance.

My comment actually goes along with one of the references at the bottom of the page, namely "Ottinger's Rules for Variable and Class Naming". One rule, "Avoid Encodings", is downright wrong. Here's the quote.

Avoid Encodings
Encoded names require deciphering. This is true for Hungarian and other `type-encoded' or otherwise encoded variable names. To allow any encoded prefixes or suffixes in code is suspect, but to require it seems irresponsible inasmuch as it requires each new employee to learn an encoding "language" in addition to learning the (usually considerable) body of code that they'll be working in.

As breifly as I can put it, encodings work across projects, and quickly become the most useful in-code documentation any code can have. It might take quite a while to learn each body of code you maintain, but you'll learn each much much more quickly if you spend a little up-front time learning a company-wide encoding standard and stick by it. Delayed gratification, that's what commenting's about.

Just as examples, can we know that a variable called "browserWindow" is a JWindow in Java? Perhaps it's now a JPanel that's simply a child in a JWindow of a browser. Is "customerCounter" going to fail once we get to 32,768 in VB? We'd know immediately, no matter where we started reading the code, if the names were "pnlBrowser" or "dblCustomerCounter".

Without hard and fast and easy to learn self-commenting encodings in code, you'll keep turning out code that's hard for members not on the original team to learn. Ottinger misses the boat on this one. I'm betting the rule came from people who learn a giant system and stick with it for the next 10 years -- if you were never going to learn or program something new, system-wide advances do lose their advantage [for those people who will never see another system].