Almost a decade ago I picked up a pair of relatively inexpensive Sound Dynamics R606 floor-standing speakers. Using the same components from their high-end line (I believe Mirage was the high-end marketing name), these were the poor-man's version. I still have them today, and they are extraordinary. I have never, anywhere, heard better sounding speakers overall, and I've either purchased or auditioned a large number of dramatically more expensive brands and models, and I've tried to follow the advice by a lot of audiophile magazine. Still, though, the voicing and realism of the reproduction that comes from the R606 is just unparalleled - I watched a DVD with them as the fronts for the first time recently, and the realism was absolutely spooky.

Of course like all speakers they aren't perfect - they can get a bit muddy for percussion in the lower range, and they aren't really suited to loud "rock" style music. Yet for other music, particularly of the female vocal genre, they are exemplary.

The only really point here is that with speakers, you don't necessarily get what you pay for: You might get much more, or much less. The only real consideration of a speaker's performance is to actually audition it.

In my prior entry, titled EXIF - Digital Photography and GPS, I opined that we would see a revolution in digital photography once digital cameras started utilizing the available GPS related tags in the EXIF data structures. I received a couple of great responses, including one by Luke Francl where he pointed me to two great links - Mappr!, which is a dynamic application that displays Flickr photos, geocoded based upon their user added tags (e.g. A flower with the keywords Seattle, Washington would appropriately display in Seattle), and Photospace, which is an application that logs GPS data on your PC, and then in "post processing", so to speak, it sets the geographical information on the images (by correlating times. e.g. a photo taken at 1:37pm correlates with an external GPS entry saying that you were at X & Y). A very nice stopgap solution until cameras themselves integrate this functionality.

[See also http://www.yafla.com/dforbes/2005/11/29.html#a201]

More often than not (depending upon context and teams) I prefer to fully qualify references, particularly in cases where there are any possibilites of collisions now or in the future (e.g. a lot of vaguely named data and business entities fall in this category, with nondescript names that could easily apply elsewhere). This just seems like good defensive programming, and yields code that isn't fragile. It won't shatter if someone adds a class to your namespace (or any other namespace that you're blindly using) that collides with a class in another namespace. For precisely the same reason I often preface instance references with this.

In this preference I am more of an exception than the rule, however - most prefer to add a using atop their namespace, and simply rely upon the compiler to sort things out. The premise being that the fewer characters exist in the code, the cleaner and more maintainable it is: If you can add a using System.Data.SqlClient to your file, then that namespace should never appear again. There is definitely a lot of validity to that position as well.

(Of course with something like the "CodeML" I described earlier, the XML would store the fully-qualified names, and developers can choose whether to display the qualified or unqualified names based upon their own preferences. It's just a display issue)

Many of the most time-consuming, polarizing debates in software development are the constant back-and-forths over trivial code style: Tabs or spaces, 2 or 3 spaces, curly bracket at the end of line or beginning of the next, and so on. While C# improves things a bit in that it, by default, does some formatting (such as curly bracket placement), they could have taken it a step further - the source should always be stored in a clear, defined and standardized XML storage format. e.g.

<namespace name="Microsoft.LameExample">
  <class visibility="public" name="MyClass">
    <method visibility="public" type="instance" name="Run">
      <call>
        <method>System.Windows.Forms.MessageBox.Show</method>
        <parameter>Hello!</parmaeter>
      </call>
    </method>
  </class>
</namespace>

I'm hardly the first to advocate this (and of course it's what most of us thought about when we first started getting a handle on XML many moons ago - how can we apply this to software development), and while I thought I was original thinking up the term CodeML, there are actually already plenty of references to it out there. It's a pretty obvious idea.

With such a structure not only would language parsing be much easier for third-parties to interact with, but most importantly it would allow each user's environment to stylistically render the code however they want. Source control systems could (should) be schema aware, intelligently doing change management, and we wouldn't have massive change sets caused by someone running a reformatter to update to the standard of the day, switching from tabs to 3 spaces (python's use of whitespace to meaningfully indicate blocks/scope is absolutely brilliant, as an aside), or updating the curly bracket standard. What a complete waste of time and effort, and what a ridiculous distraction from actually solving problems.

Of course we still have the issue of case sensitivity - I'm still on the fence about this. I love C & C++, and I've always hung onto their case sensitivity out of habit ("real programmers pay attention to case"), yet it's possibly just another needless distraction. There really are very few instances where you want overlapped names, differing only by case.

It was, I think, an ugly decision to incorporate case sensitivity into .NET.

If there were no case sensitivity issues then this too could be an environmental option (e.g. all identifiers are stored in upper or lower case in the XML file, but then rendered according to user preferences - consts all upper case, parameters camel cased, public methods pascal cased, and so on. No need to "correct" such a menial thing in other people's code. The IDE knows what each of these things are and what their visibility is, so there should be no need to crystalize such a pseudo-Hungarian notation in our code).

This is of course just off-the-cuff thoughts after hearing yet another reformatting debate, so temper your criticism accordingly. I'm also pragmatic enough to realize that making a standardized schema for something with as many edge conditions and exceptional circumstances as source code isn't quite as easy as it sounds.