ISerializable - Roy Osherove's Blog

Your post just shows how each person gets used to something and then dislikes anything different, regardless of whether it's better or not.

I've never done any VB-like programming, and on the rare occasion I've even had to extract (ripoff!) six lines of code from VB code from a VB project it has pissed me off no end.

Firing up a VB project for 2 minutes, here's what pisses me off:

Intellisense: I want to access Me.myVariable.

In C#, I type this.myV until it comes to the member I want, I press enter - it autocompletes the rest of the variable.

In VB, I type this.myV, press enter - it gives me the variable and adds the new line!

Why would I want a new line? I'm just about to say Me.myVariable = x, so why do I have to go back and do this?

Why do you need all those redundant words like End If?


On your complaints, case-sensitivity is a fundamental language feature, and unlike some of your other complaints cannot be changed as it's part of the standard.

It's also very cool

public class myClass {

private bool myBool;

public MyBool {

set {
myBool = value
}
get {
return myBool
}
}

two different variables there....

Automatic creation of "()" braces:

Since I've never had this I don't miss it.....

It really doesn't take me too long to go MyFunction(.... Plus the ( gives me the intellisense to remind me of the parameters the function is expecting.

I guess VB programmers don't have to type many brackets, but in C# you get used to it, and I don't think I would want or use this feature

With. I'm sure there's an article I read about why this is bad, but it's really hard to google for 'with', so I can't post the link..... I did use it once in JavaScript, and I felt it tended to obfuscate things a little though.

Hi Roy,
I liked your list of potential improvements to the IDE and I have to say I agree with all of them. Case sensitivity seems to be one of those annoying things that seems to a feature of C syntax languages and operating systems and I agree with you it is a pain. You should never have two variables with same name except for case.

As for the with statement I remember having this discussion at the PDC in 2000 and seems that the developers did not seem to see a need for it.

I surprised the person who complained that you are looking at everything from a VB point of view did not complain at your mention of "edit and continue" for C#. I remember seeing a comment in MSDN chat where Eric Rudder was asked about adding "Edit and Continue" for C# and he said he did not think there was the demand for it from C# developers.

I developed in about 10 different programming languages over time, including Java, vb and C# and really want all the productivity aids that come with VB and especially "Edit and Continue".

You are definitely on the right track.

Martin Spedding

Case sensitivity is important to me, because it makes my code cleaner. It stops me (and other people) from writing

MySpecialMethod()

as

myspecialmethod()

or

MYSPECIALMETHOD()

It forces code to be uniform. I understand that not every VB programmer is this sloppy, but I've run into quite a lot of hard-to-read code because case was used inconsistantly.

(I'm speaking from when I used to be a VBScript programmer, I haven't touched VB at all.)

I don't think it's vital to the language, I just like the constraint. :)

matthew:
Pressing TAB instead of Enter fixes your issue :)
as for "wordy" - I agree. I think VB.Net can sometimes be too wordy for its own good - but it sure is self-documenting - the wording fo access modifiers might seem redundant - but it is much more self documenting than curly braces...
I still like curly braces better(I'm a VB traitor..)
as for naming variables - I don;think it's cool to have two variables named exactly the same with only casing diffrentiating them. It makes for less understandable code. The fact that you had to mention "two variables there" in your code shows exactly that - It should be easy to spot and read two different variables without getting confused between them.

Paul:
That's what I'm talking about - In VB you can write MYVARIABLE but you'll get automatically formatted text to the name of the variable, so if it was named "MyVariable" - your text will automatically turn into that casing... how easy is that? :)

Leave case-sensitivity alone. It will never change, nor do most C# developers want it to.

Case sensitivity leads to bugs.

"That's what I'm talking about - In VB you can write MYVARIABLE but you'll get automatically formatted text to the name of the variable, so if it was named "MyVariable" - your text will automatically turn into that casing... how easy is that? :) "
Not always. If you are typing some code and realize you have to declare a variable, you type in the statement using hte variable and then you type the declaration above it. AFAIK, the statement will not change based on another casing.

Personally I think code which relies on case sensitivity to run properly is not that good and it shows lazyness, because coming up with a new good name is not that hard but takes a little time and the shortest way out is to simpy use the same name with another casing...

Oh dear -- what have I started? I didn't mean to word my original comment so personally, apologies are due, please accept them Roy.

I've a lot of pent up anger to disperse on VB programmers in general, yes I used to be one, until I discovered the light about ten years ago, along with curly braces and square bracket indexers. It's only fair that if I flame you for your post, I give you (and many others) the chance to do likewise for my reasons.

My biggest problem with VB in general is that something that can be so "self-documentating" as you put it can be simultaneously so woefully inelegant. In general Roy, I disagree with your principals for suggesting changes to the language, not really the changes themselves. To put it simply, I believe there to be two broad camps of programming methodologies, the VB way, and the C way -- the languages may have changed over the years, but the developers' frames of mind remain the same. I'll rant about the VB way:

The 'VB' way.

I'm sure you're aware of the history of Visual Basic, it was originally built as a application prototyping environment, for quick turnaround of concepts into working code. Every single feature that has been added to the language and the dev ide have tried to accomodate this scenario. Every little thing seems to be designed around the lazy programmer. Just spit out grammar as it comes into your head and let the background-compile process draw little squiggley red lines underneath your code -- you can fix it later. Your pinky has slapped the capslock key? Never mind, let's code the rest of this module entirely in UPPER case, the compiler doesn't care. Option Strict? what's that? -- "lets not bother declaring any variables, I'll just make them up when I need them." Option Base 1? "I can't get my head around zero-based indexes, let's all start at 1, except for this module over here". "I think I'll use zero based indexes there. I'm not sure why". It's syntactical verbosity is just astounding, the amount of syntactic sugar is enough to induce programmatic diabetes. Edit and continue is more pandering to this hack up a demo ethic, IMO. Used correctly, it can be a help, but in my experience it caused me to think less and brainfart more.

You see where I'm going with this? There was no discipline in VB. Yes, you could argue that VB.NET changes all this, but giving a VB programmer a copy of VB.net doesn't change their habits. We have several VB programmers here, and our shop is moving to .NET. I've insisted that the VBers start afresh with c#. My reasoning behind this is that if they were to learn VB.NET properly, they should treat it as a completely new language. But, coming from VB 6, they will see all these things and keywords that are familiar to them and they'll never really mentally shake off the connection (and the bad habits). I strongly believe that they'll take to OO programming faster and with a better attitude if they go with a new language, a perceived blank sheet per-se. I may be wrong.

I think this endless pursuit of making it easier for the programmer has gone beyond aiding creativity. It is positively eroding it.

Back to your points:

- Background compile
(discourages discipline: see above rant)

- Case insensitivity
(discourages discipline: see above rant)

- '[]' instead of '()' for array indices
Sounds like you're getting confused between languages Roy.

- VB.NET-like Intellisense for enums and namespaces writing
Sounds like a good idea to me. I'd imagine it awaits us in the next rollout of the IDE.

- Automatic creation of "()" braces on method calls
This sounds like more help for VB programmers used to typing function calls without parentheses. It had never occurred to me. How much productivity are you going to save with the s

(continuation)

- Automatic creation of "()" braces on method calls
This sounds like more help for VB programmers used to typing function calls without parentheses. It had never occurred to me. How much productivity are you going to save with the saving of two characters?

- With like functionality VB.NET
As pointed out in various forms to you:
using (q = Namespace.Object.Object) {
q.property1 = "a";
q.property2 = "b";
}

Admittedly, you've had to type an extra four characters, but hey, life is tough. VB and C# are different for a reason. That reason is so they are different -- it's that simple. VB.NET has underscore line continuation, a 'With' keyword, parentheses for array etc because it is Visual Basic. I believe that VB has been put together to enable speedy mock ups for a broad spectrum of applications, with an emphasis on strong visualisation and good readability for the lay coder. C-syntax to me has always been about the embodiment of abstract concepts, its concise grammar lends itself especially well to this IMO. I'd like to think I'm not a C-syntax snob, but it appears I am.


And last, but not least, I am currently involved in porting a large multitier app from VB to C#. This has been the source of countless rage fits. Again, apologies for getting a little too personal on the rant.

Subscribed.

Roy, I liked your list. I agree with all except Case Sensitivity. It should be smarter and automatically adjust like VB, but then it wouldn't be C# anymore. I like using VB primarily because the VS.NET editor seems much smarter and supportive than C# (though I have coded almost exclusively in C# for the last year.) Keep on doing what you're doing, whether its "stereotypical" or not!

I'm with you Roy.

Thanks for the feedback guys(especially Oisin). I've learned a lot :)

Frans Bouma's blog

heLP .Net Blog

Matthew said:

-----------------------
It's also very cool

public class myClass {

private bool myBool;

public MyBool {

set {
myBool = value
}
get {
return myBool
}
}

---------------------
There is so much to say about case sensitivity from a psychological point of view that I wont even start. Suffice it to say that its NOT cool. Matthew, here is your code again only this time it will cause a stack overflow every time you set the MyBool property:

----
public class myClass {

private bool myBool;

public MyBool {

set {
MyBool = value
}
get {
return myBool
}
}
-----

Go ahead. Run it and see what happens when you create an instance of myClass and do "myVar.MyBool = False". Now without using the debugger to step through the code, try and work out what's going on :). Now throw in several thousand lines of code, a few differences in the way your programmers use case-sensitivity in identifiers and voila! - CHAOS.