aliozgur posted on April 23, 2008 09:29
As a former long standing Delphi developer (actually I am still maintaining some Delphi projects) I really love the Delphi IDE. Visual Studio is also a fantastic IDE with lots of productivity features. But I always missed "Numbered Bookmarks" of Delphi. This feature really saves time while navigating source code back and forward. Finally I found DPack addin which has Numbered Bookmarks and emulation of some GExperts for Delphi features. DPack is also a free addin, I would recommend this addin to former Delphi developers . You can get DPack from here.

Posted in: .NET Development  Tags:

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

 


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.

 


Posted in: General Programming   Tags:

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.
More...


Especially for Windows XP machines after Service Pack 2 (SP2) is installed some WMI related problems can occur due to security updates included in sp2. These problems cause PragmaSQL not to perform license check correctly and as a result application does can not start. Some probable solutions to this WMI related problem are
More...


Posted in: PragmaSQL  Tags: