Implicitly typed local variables introduced in C# 3.0 specification is very cool. Those who used VB and some other scripting languages are familiar with untyped variables and other who used VC++ and Delphi will remember the Variant type. But implicitly typed variables are different in C# 3.0. For example in VB actual type is determined at runtime and that is true for the Variant type too,but the actual type of the implicitly typed local variables are determined during compile time which eliminates lots of headache. C# 3.0 specification introduces "var" keyword to define an implicitly typed local variable. For example

C#-Code:

 


public void SomeMethod()
{
    //int x = 12;
    var x = 12;
    //double y = 12.0;
    var y = 12.0;
    //string z = "Sample string";
    var z = "Sample string";
    //int[] k = new int[]{1,2,3,4};
    var k = new [] {1,2,3,4};
} 

Returning back to the original issue, using implicitly typed local variables saves lots of coding time and may be considered as a must for LINQ powered C# code. But do not forget that every piece of code may be debugged or reviewed by another person and by you some time later which brings code quality issues into scene. Readability is one important sign of the code quality and in some cases and depending on your coding practices using implicitly typed local variables may decrease your code quality as a result of difficult to read/review code. The key point here is how we review a piece of text as an average human. From my personal experience I can say that

• We tend to anchor to the headings and try to understand the details backreferencing the heading
• We may need short descriptions or walk throughs before we start understanding a complex issue
• Not to get lost in a long text we tend to summarize what we have understood so far
• When we finish practicing the text we try to infer a result from what we have highlighted in previous steps
• After inferring a result we can start to invent our own understanding of the subject

I think that scheme is applicable to debugging and code review practice. Knowing these we, as software developers, should avoid practices which may turn our code to a nightmare for other developers. I think if you

• Use meaningfull names for your classes, methods and variables. Every code entity, be it a class, a varible or a method ,  should mimic its purpose of existence by its name if possible.
• Write atomic methods. I mean writing methods that perform only a single well defined task.
• Comment your code well (Some developers tend to write more comments than the actual code, if you do this I suggest you to review your code you might be doing something wrong or incomplete)
• Keep the level of method chaining in a reasonable level

you shall use implicitly typed local variables without hesitation. But if you have readability problems with your code be carefull while using implicitly typed local variables, that will bring more complexity to your already hard to grasp code.

For a while I am thinking about the Microsoft's support to open source projects. Some news that attracted my attention to this issue were

• Foundation of CodePlex, open source project hosting web site of Microsoft
• Ms-PL license developed by Microsoft  
• Release of .NET Framework libraries  source code . Read more
• Release of ASP .NET MVC source code. Read more

Heritage

Microsoft has developed very successfull technologies through history. COM/ActiveX formed a good baseline for MS platforms and related runtimes like MTS, COM+ and DCOM were a must for enterprise level application development targeted at MS platforms. VB was a fantastic programming language, even I've never written single line of VB code I remember how my co-workers rocked with VB, ASP was not perfect but it was, actually it still is, productive and easy to learn and VC++ powered with MFC was the programming language of choice for lower level software development. All these runtimes, frameworks and languages were not perfect, but they did succeeded in helping software developers to produce valuable software. However some of these technologies required software developers to have some sort of geek talent. For example it was very difficult for a regular software developer to write some sort of event sink COM code or programmatically configure the DCOM environment. I think Microsoft has learned more than we expected from the history I briefly tried to explain. Now we are at the age of .NET and related technologies and personally I expect less hesitation than the previous experiences we all ran through. 

Communities behind technologies 

I think all these steps and efforts are very much related with the direction Microsoft plans for the .NET Framework, bunch of foundation frameworks (like WWF, WPF and others) and it's flagship product Visual Studio. These steps also show that Microsoft analyzed Java community very well. Communities have direct impact on the directions of the technologies, once you build (or help to build) an active community around a technology it is very likely that you will end up with long lived and more mature product.

The thin line between enforcing and empowering

Microsoft has very bad history record about enforcing developers to stick to the technologies and practices they offer, leaving very limited space for our own judgement of truth. For example it was very hard practice to write COM code without VC++, even with VB that was very hard (I exclude Delphi). But Microsft's approach changed over time from enforcing to empowering developers starting with the establishment of .NET Framework and related technologies. For example release of some well known patterns as application blocks and later bundling these application blocks to more mature foundation class libraries is a nice example for empowering. Even better example is the release of ASP.NET MVC open source, .NET developers will not have to stick to default WebForms view engine and they can develop alternative view engines that will work with ASP.NET MVC.   

Customer and developer trends

Today software developers focus on interoperability, extensibility, maintainability and testing more than ever. This trend forces big brothers of the industry to develop different licensing approaches, different marketing strategies and development platforms as well. I have never understood that what did Microsoft gained from hiding the source code of a piece of software like TextBox control or a GridView control. That kind of source code was a big value, say 20 years ago, but today it has no value I guess, since software users demand more Business Intelligence and we, software developers, need robust frameworks and development tools to provide this intelligence.

Software Development Ecosystem (targeting MS platforms)

I like the term ecosystem very much. Because this term can be used to describe an environment containing many diverse components surviving together in a nice harmony (balance). Software development is in a way an ecosystem containing actors, processes, tools, frameworks and lots of communication. The diversity of the components in a software development ecosystem makes it hard for a single provider, even that is Microsoft, to provide all the facilities needed inorder to form some kind of harmony. I think Microsoft realised this very well and backed off from the obsession to provide every component needed in this ecosystem. By the way in Turkey we take diversity as granted and I believe that applies to software development ecosystem too, more colors make a better painting. Returning back to the issue, I'am sure that Microsoft's effort for openness will trigger other actors to enter the ecosystem and existing ones will have to reshape themselves to adapt to the new conditions. I expect new and more mature components to evolve while old ones evaporate. Nowadays we are in the middle of evolution process which will produce much than we expect.

Conclusion

It seems that Microsoft is doing more right things than ever. I expect this process to introduce innovative and open source technologies (I mean community initiated open source technologies) to the .NET community. We, as software developers, shall be more confident about using Microsoft tenologies than ever. I recommend you to keep an eye on these projects

• CodePlex
• Singularity Project
• ASP .NET MVC 
• Castle Project and NHibernate
• LINQ powered technologies
• Programming languages and compilers targeting the CLR. (Phalanger, IronPython)
• BlogEngine .NET
• Cuyahoga Project
• DotNetNuke project
• BugNET Project

Some PragmaSQL users were notifying me about a strange but deadly serious error caused after recovering from a server connection transport-level error. To reproduce the error follow these steps:

1- Open PragmaSQL Editor and choose a connection from Saved Connections list to connect. I will assume that Default Database of the selected connection is DatabaseA 

2- In the opened script editor change database to DatabaseB

3- Open to Microsoft Sql Server Management Studio and from Management node select Activity Monitor. Find the process for DatabaseB created by PragmaSQL application and kill that process.

4- Return to PragmaSQL editor and try to execute the select statement for the selected database, that is DatabaseB.

5- You will get transport-level error after trying to execute the statement for the first time.

6- Try to execute the statement again and this time you will succeed. But the statement was executed on the initial database, that is DatabaseA not in DatabaseB (selected one ). This error may cause very serious problems if you were trying to modify data you would simply modify the data in wrong database.

The problem is actually with database change code inside PragmaSQL which is not really a bug but misusage of SqlConnection class's ChangeDatabase method. While I was coding the change database logic I did not realy realised that ChangeDatabase method does not modify the Initial Catalog property of the ConnectionString, actually there is no way to modify the ConnectionString property of the SqlConnection object once it is opened. SqlConnection object in the script editor is created and opened only after the user changes the selected server, database changes does not cause a new SqlConnection object to be created and opened, we simply change the database property of the existing SqlConnection object and that is it. I did not considered SqlConnection object's error recovery scnearios (transport-level error for example) at all. The fact is that SqlConnection class recovers from transport-level error very well but uses the ConnectionString property to reopen the connection, no matter what was the database before the error SqlConnection object always restores connection to Initial Catalog property specified in the ConnectionString.

Very ugly bug, but I am happy to resolve that one. Upcoming 1.0.0.34 version will include solution for this issue.