Archive for February, 2007|Monthly archive page

Runtime Editing (+1 VB.Net)

It seems that when running a C# project, you can only edit C# code during runtime.

VB.Net allows editing of any source code.

Shades of Beautiful

As colored crayons, when in my hands,

Draw the mind’s delight,

So, without hold, my love unfolds,

…When you are in within sight.

These colored sticks of creativeness

Unwind and scatter here

Upon this page, this flattened stage

On which I will draw you clear.

In this endeavor I must be clever,

And elect colors with care,

For if I do then I’d capture you,

…From brush to page through hair.

..Your lips, your hips, your fingertips,

…And half-unbridled smile…

Without constraint, and never faint,

…Your all-alluring style.

You’re fourteen shades of lovely,

With two shades of divine,

Sixteen shades of beautiful,

And every shade is mine.

And from each color, comes another

Shade to paint my world,

And with attention… detailed, I mention,

I watch it all unfurl.

 

Copyright 03-14-2003 Joshua R. Mouch

Go to Definition (+1 VB.Net)

It seems that C#’s “Go to Definition” is incapable of navigating to a VB.Net source file.  Instead, it just takes you to a meta-data version of the file (without source code).

VB.Net does not have a problem navigating to C# code.

Find Definition (+1 VB.Net)

I use find definition quite a bit to quickly jump to a method or property definition.  Just hit F12, and you’re there.  However, C# adds an additional step.  If a method is overloaded, it will pop up a “Find Symbol Results” window, and ask which overload you would like to go to.  VB.Net infers which you would like to go to based on the parameters that are being fed to the method, therefore removing that step.

Creating Blocks (e.g. Classes, Methods, If…Else, etc.) (+10 VB.Net)

Both VB.Net and C# have automation built in when it comes to creating blocks. However, C#’s implentation is quite a bit less robust.

Creating a new block

VB.Net

To Create a new class, method, and property in VB.Net, you could type:

public class TheClass<enter>
public property TheProperty as string<enter>
<down><down><down><down><down><end><enter>
public sub TheMethod<enter>

Result (including important cursor positions):

Public Class TheClass
Public Property As String
Get
|
End Get
Set(ByVal value As String)
|
End Set
Public Sub TheMethod()
|
End Sub
End Class

C#

To Create a new class and method in C#, you could type:

public class TheClass {}<home><enter><up><tab>
public String MyProperty {}<home><enter><up><tab>
get {}<home><enter><up><tab>
<down><enter>
set {}<home><enter><up><tab>
<down><down><down>
public void TheMethod() {}<enter><home><enter><up><tab>

or (using shortcuts)

public class TheClass {}<ctrl-enter>
public String MyProperty {}<ctrl-enter>
get {}<ctrl-enter>
<down><enter>
set {}<ctrl-enter>
<down><down><enter>
public void TheMethod() {}<enter><ctrl-enter>

Result (including important cursor positions):

public class TheClass {
public String MyProperty {
get {
|
}
set {
|
}
}
public void TheMethod() {
|
}
}

C# Inconsistencies

If there is a syntax error (e.g. unclosed block) near the new block, it will not be auto-completed or auto-formatted.

Comparison

Luckily for C#, <ctrl-enter> exists. Otherwise, you would have to type <home><enter><up><tab>. However, it took me a while to find this shortcut and get used to using it.

Without the shortcut, there are 6 extra keys to hit. With the shortcut, there are only 2 extra keys plus a combo key instead of just enter (so 3 extra keys).

On top of the extra keys in C#, you must make sure all the syntax is correct or else auto-complete will not happen.

Auto-formatting of existing blocks

This is where C# really shows its inferiority. Once stuff gets moved around, the only way to get back to standard formatting is to make sure there are no syntax errors and then hit <ctrl-K><ctrl-D>. Well, that or manually move it… but are we using an IDE here or Notepad?

There are lots of reasons this C# will not auto-format your block for you even after hitting <ctrl-K><ctrl-D>. For example, if a previous block is unclosed, or if there is a syntax error somewhere nearby, such as missing a ‘;’ inside the block.

Feelings on the Matter

I find myself constantly hitting <ctrl-k><ctrl-d> (shortcut for format document) while programming in C#, since the formatting of the document becomes non-standard after a bit of editing.

Basically, VB.Net’s philosophy is: auto-format all the time, unless you are talking about a line continuation (using an underscore character).

C#’s philosophy seems to be: auto-format only when finishing a block and there are no syntax errors to speak of nearby.

The C# versus VB.Net debate in a Slightly Different Light (I Hope)

The C# versus Visual Basic.Net debate has been an ongoing one since the inception of the .Net languages.

Let me start off by saying that I am not so much concerned with the language/syntax itself as with how quickly I can finish my project using that language, and how good the code is afterward. I recently read a great quote: “Programmers don’t like to code, they like problem solving.” I could not agree more.
From a purely language/syntactical perspective, I can save you the trouble of reading this and tell you that it’s purely

Dividing Lines Between Member Groups (+1 VB.Net)

VB.Net’s editor has a nice feature that makes it easy to scroll up and down, looking for a method or property. VB.Net will insert a single pixel line between each property, method, and group of fields.

My guess is that C# doesn’t do this because of the more relaxed formatted. However, this isn’t too large an obstacle. With everything else that the C# editor is missing, I’m am guessing that it just didn’t seem important enough.

Steve Jobs on Unions

There is some negative review on Steve Jobs statement regarding the state of school unions.  While I am not an Apple fan, I do need to agree with Steve on this one.  Being from Michigan myself, and seeing the recent loss of so many of our factories due to unions, his statement repeats what I have believed for a long time: Unions served their purpose years ago, but now, they’re out of control.

I’m not an economist, so forgive my common-man terminology and views.

Unions will increase the wages and increase wages to the point that people who’s job it is to insert part A into slot B will be making six times the amount of money as somebody who’s job it is to insert bun A onto meat patty B.

What’s wrong with union members making so much money?  I have a lot of factory worker friends, and of course I would love to see them make all the money in the world.  However, by them making all the money in the world, the products they are making, in turn, cost all the money in the world.

In order to compete with foreign factories, our own factories are almost being pushed oversees because of the incredible wages we pay our factory workers due to the unions.

Would you like a true example?  Here is one from Flint, Michigan.  Recently, Delphi gave its union an ultimatum.  Either lower the worker’s wages, or Delphi would be forced to move out of Flint.  Guess what the union did?  They stood their ground, and now Flint has no Delphi.  In Delphi’s defense, they told the union what needed to happen for them to survive.  The union cared more about the sweet cash they were raking in.

The truth of it is that there will always be a need for those who make less then you.  It’s a hard truth, but one we need to learn in order to keep companies in the United States.  I dream for the day that technology complete removes any pay gaps by doing all of our menial (low paying) work for us, but that day is not here.

So, in response to that article, the only reason teaching hasn’t been outsourced oversees yet is because we haven’t found a good way to do it.  Keep that in mind, teacher unions… you have been warned.

Syntax Consistency among Class Members (Events, Properties, and Methods)

VB.Net wins hands-down for being consistent in its syntax. Consider these following examples.

First, let me quickly define my terminology. By implicit, I mean the compiler generates code behind the scenes. By explicit, I mean WYSIWYG. The implicit properties you see are actually a proposed C# language change called “Automatic Properties”. You can read about it here.

Consider the following C# event, property, and method cases.

// IMPLICIT
event <type> MyEvent;
<type> MyProperty { get; set; }
// implicit method is not possible

// ABSTRACT
abstract event <type> MyEvent;
abstract <type> MyProperty { get; set; }
abstract <type> MyMethod();

// EXPLICIT
event <type> MyEvent {add{} remove{}}
<type> MyProperty {get{} set{}}
<type> MyMethod() {}

Now consider these VB.Net cases. I have not found what the VB.Net syntax will be for automatic properties, so I am making a best-guess.

// IMPLICIT
Event MyEvent As <type>
Property MyProperty As <type>
// implicit method is not possible

// ABSTRACT
// abstract event not possible
MustOverride Property MyProperty As <type>
MustOverride Function MyMethod As <type>

// EXPLICIT
Custom Event <type> MyEvent : Add…End, Remove…End, Raise…End, End
Property MyProperty As <type> : Get…End, Set…End, End
Function MyMethod As <type> : End

C# Inconsistencies

  1. Event has a keyword, but method and property do not.
  2. Implicit properties has accessors. Implicit event does not.
  3. Abstract property has accessors. Abstract event does not.

VB.Net Inconsistencies

  1. Explicit event requires “Custom” keyword.

Proposal objections

One thing to note is that some have suggested the new Automatic Properties in C# be formatted like this:

property <type> MyProperty;
readonly property <type> MyProperty;

This would change the C# inconsistencies to this:

// IMPLICIT
event <type> MyEvent;
property <type> MyProperty;
// implicit method is not possible

// ABSTRACT
abstract event <type> MyEvent;
abstract <type> MyProperty { get; set; }
abstract <type> MyMethod();

// EXPLICIT
event <type> MyEvent {add{} remove{}}
<type> MyProperty {get{} set{}}
<type> MyMethod() {}

C# Inconsistencies

  1. Event and implicit property have keywords, but method, explicit property, and abstract property do not.
  2. Implicit properties has accessors. Implicit event does not.
  3. Abstract property has accessors. Abstract event does not.

My Suggested Automatic Property Format

I agree that automatic properties should introduce the keyword “property” into the C# language. However, with this change, property should also optionally be allowed in non-automatic property declarations. This would reduce the inconsistencies considerably.

This would change the C# inconsistencies to this:

// IMPLICIT
event <type> MyEvent;
property <type> MyProperty;
// implicit method is not possible

// ABSTRACT
abstract event <type> MyEvent;
abstract property <type> MyProperty;
abstract <type> MyMethod();

// EXPLICIT
event <type> MyEvent {add{} remove{}}
property <type> MyProperty {get{} set{}}
<type> MyMethod() {}

C# Inconsistencies

  1. Event and property have keywords, but method does not.

Syntax (+5 VB.Net)

Hands down, VB.Net has much better keywords than C# does. The problem is that C# gets its syntax from its C++ roots. In turn, C++ gets its syntax from the philosophy that “if you can use the same word/character to do 20 different things then you’ve written a good language.”

The biggest three exceptions are that I like the fact that C# ditches “Sub” and “Function” in favor of a combined approach, and I think the VB.Net AndAlso/OrElse keywords are pretty silly, and biggest of all is that using {} for block logic is much more flexible and quicker than using VB.Net’s “Whatever/End Whatever” syntax.

Here are some specific examples where the VB.Net keywords/syntax is better:

Constructor

VB’s constructor syntax is more intuitive and requires less typing because if the class name changes, there is no need to change the constructor’s name as well.

VB.Net

Sub New()
End Sub

C#

WhateverYourClassNameIs() {
}

Properties (VB.Net is better)

VB.Net

Property MyProperty() As Type : End Property
Default Property MyProperty() As Type : End Property
ReadOnly Property MyProperty() As Type : End Property

C#

Type MyProperty { }
Type MyProperty[] { }
Type MyProperty { get; }

Now before you say, “but C# requires less typing, so that makes it better!”. Take this into account. C# will be adding an “Automatic Property” syntax. However, because of C#’s terseness, the syntax that is being proposed is causing a lot of concern. One of the proposed solutions is to make these C#’s properties look more like VB.Net’s properties (thought I don’t know if the proposers realized this) by adding the “property” and “readonly property” keywords.

Class Modifiers (VB.Net is better)

“MustInherit” versus “abstract”

“NotInheritable” versus “sealed”

“MustOverride” versus “abstract”

“NotOverridable” versus “sealed”

“Overridable” versus “virtual”

If I were to ask you, “What is a sealed?” Your answer could be “A dead Antartic mammal”. If I asked you, “What is a NotOverridable?” You could only reply, “Something that is not overridable. Maybe a broken bridge?” But at least you would be closer.

Selection Statements (VB.Net is better)

The biggest problem I have with C#’s selection statement (switch) is that it requires a “break” keyword in each case. How often do you actually run cases together? Even if you do run them together, VB.Net’s approach of allowing multiple cases to be specified makes more sense.

VB.Net

Select Case someEnumerationValue
Case EnumType.One
Case EnumType.Two, EnumType.Three
Case Else
End Select

C#

switch (someEnumerationValue) {
case 0:
break;
case EnumType.Two:
case EnumType.Three:
break;
default:
break;
}

Method Declaration (C# is better):

VB.Net

Sub MethodName(argument As ArgumentType) : End Sub

Or

Function MethodName(argument As ArgumentType) As MethodType
End Sub

C#

MethodType MethodName(ArgumentType argument) {}