One of the raps that VB sometimes gets is that we’re too “verbose.” There are a few things that we think might contribute to this perception that we’re looking at for the future, but I had an interesting flash the other day. I wonder how much the fact that we uppercase our keywords affects our perception? So I built a bootleg of the compiler and tried it out on some code of mine. Before:
Private Function ParseSimpleNameExpression() As SimpleNameExpression Dim start As Token = Peek() Dim name As SimpleName = ParseSimpleName(False) Dim typeArguments As TypeArgumentCollection = Nothing If Peek().Type = TokenType.LeftParenthesis Then Dim leftParenthesis As Token = Read() If Peek().Type = TokenType.Of Then typeArguments = ParseTypeArguments(leftParenthesis, False) Else Backtrack(leftParenthesis) End If End If Return New SimpleNameExpression(name, typeArguments, SpanFrom(start)) End Function
After:
private function ParseSimpleNameExpression() as SimpleNameExpression dim start as Token = Peek() dim name as SimpleName = ParseSimpleName(false) dim typeArguments as TypeArgumentCollection = nothing if Peek().Type = TokenType.LeftParenthesis then dim leftParenthesis as Token = Read() if Peek().Type = TokenType.Of then typeArguments = ParseTypeArguments(leftParenthesis, false) else Backtrack(leftParenthesis) end if end if return new SimpleNameExpression(name, typeArguments, SpanFrom(start)) end function
It’s a little frightening how much just changing the casing of our keywords makes us suddenly look like C#, at least to my eyes. I’m curious what people think of the idea? Would you like to see us switch to lowercase keywords? Provide an option?
(My replies to this entry maybe a bit slow–I’m going to be on vacation for a little while, but something to think about while I’m gone…)
I am started as VB developer but now I am in company that is using C# I dont care wich one I use. Both using the same framework and that is the most complicated part to learn.
There for I ask: "Why is it frightening to suddenly looking bit like C#?"
Personaly I like lowercase better. Even tough I like VB none case sensitive variables more over C# way of doing it 🙂
Actually, I think it looks a bit like Python
I like the lowercase version. For some reason it looks more geeky to me 😀
Case of the keywords doesn’t make much of a difference to me. I think being able to just write End to close code blocks would do more to abbreviate the verbosity (leaving the trailing block keywords as an option, of course)
I would vote for the lowercase version. I think it helps the keywords become less of the focus and blend into the background a bit. It lets you more easily see the important part of the code. To me, the uppercase keywords are a little like people who SHOUT WITH ALL CAPS.
Of course, this would cause tons of casing wars. People checking in code just to change the case, etc. Maybe it’s not worth the effort.
To be honest, I haven’t used VB in years – so I’m not sure my vote should count. C# feels much more clean to me. I don’t want to start a C#/VB war, but if you want more info, let me know.
Wow… the lowercase keywords look really cool.
I’m a big VB fan and wouldn’t mind at all to be forced into using lowercase keywords
DM
If you leave it as non-case sensitive, then it’s just pretty printing. I think I’d prefer it to be the way it is now, but I’m not dogmatic about it. If you make it case sensitive, it might as well be C#.
I always thought lowercase keywords looked childish, like someone too lazy to bother capitalizing sentences.
Looking at the side-by-side, I now think that was foolish. I’m not saying that I now think VB looks better in lowercase, but rather that I see no difference. My mind seems to parse both versions equally well.
Why not, in VB having options make senses.
we have option for enforces explicit variable declaration or not.
we have option for implicit data type conversions.
We have (sadly) the possibility to use a default instances to handle a form (a terrible mistake in my opinion).
So unlike C#, VB.NET allows people to use the language as they like… so I think it may be a good idea to let people choose the casing of keywords.
And why not, an option to stop the backgroup compilation which can be annoying when you paste a large amout of code from another project (you have not the time to correct the syntax and you have one hundred errors !!)
By the way VB.NET really rocks, I use C# sometimes but I love code with VB. I have never had such a pleasure since the good time of hacking my Atari 520st !!!
Continue this good work, the next features (linq et co) seems great !!
Sorry for my poor english (french inside)…
I actually like the increase in whitespace lower cases gives us, but not everywhere. I’d still like ProperCase for keywords like Private and Function.
Ideally what we should have is a dictionary for keywords, where we can specify the case used by pretty formatting. And even nicer if we could have colours i n that dictionary as well.
<keywords>
<keyword name="Private" casing="Proper" color="blue" />
<keyword name="Dim" caisng="lower" color="grey" />
….
</keywords>
Then load this into memory when VS starts, and pretty the code accordingly 🙂
I prefer the proper title-cased keywords myself, as it is now.
I never actually type the keywords that way, I just love that VB fixes them all for me as I go along.
It’s great the way it does it with the variables too. I only ever capitalize my variables when I first define them and then type them all in lower-case in the code and VB does the grunt-work for me and fixes them all.
God bless VB.NET and all who use her!
I love the lowercase keywords but I think this should be as a user preference to cater for different tastes and to help VB developers fight off the semicolon guys as they try to thrash the language and the only thing they can come up with is that it is verbose!!
Lower-casing VB keywords in order to gain a bit of wrongly imagined C# elan is a waste of time and effort. The only worse decision re casing that I can think of is to make VB case-sensitive.
If VB developers are found to suffer severe C# envy, I suppose it would be possible to all them to insert French braces throughout their code, which the compiler would ignore (except where needed).
Instead of considering cosmetic changes, I’d suggest bringing VB to full parity with C# by reinstating, for example, array and collection initializers.
–rj
Yes! This would be a great option, but why stop with the keywords?
http://onemoredeveloper.blogspot.com/2007/07/vbnet-capitalization.html
Yes! This would be a great option, but why stop with the keywords?
http://onemoredeveloper.blogspot.com/2007/07/vbnet-capitalization.html
I definitely think VB should NOT switch to lower case keywords. 99% of the code already uses the current scheme. However, I think it would be great if VB gave more control over presentation in the IDE. Why should the behind-the-scenes code be so closely tied to what’s displayed on screen?
VB should keep the current case for what’s saved to the file, but allow the user to pick how it should be displayed.
Scott’s idea for automatically capitalizing all code is good too, but the only way I can envision it working is to introduce a user-defined separator for words, so that I could type something like "public class my-class-name" and VB would change it to "Public Class MyClassName".
#0, I agree with Roger Jennings whole-heartedly, you all really need to focus more intently on all those useful features you teased us with and cut or have been floating from future version to future version; Believe it or not a VB dev might want to declare a nonserialized event in fewer than 10 lines of code. When I suffer C# envy it’s not because of keyword casing – it’s because of the glaringly obvious omissions of useful functionality I find in non-101 applications!
#1, VB is more verbose than C#, nothing will change that – I actually prefer it.
#2, COBOL makes VB look beautifully terse.
#3, for those speaking of "forcing" and "switching" this is a cosmetic change only, the compiler does not and never has cared about the case of anything, keywords included.
#4, QBasic (my first language) used all UPPERCASE keywords. I find this discussion funny with that in mind. The recasing of keyowrds and identifiers has always been a significant immediate feedback in my coding process (since QB) that I’ve written a valid statement, not doing so would really freak me out.
#5, I hate it when people use all lowercase keywords in SQL. Blending in is rather distracting. They are keywords, not common local variables (like i) and should be emphasized as such.
#6, it looks more like javascript than C#.
#7, the option of turning of background compilation is both good, and would probably implement this "feature" at the same time (hint, hint).
I’m confused why you needed a bootleg of the compiler? As Anthony pointed out above (#3) the compiler does not care about the casing of keywords.
I would have expected (and I haven’t tried) that the lowercase code above should compile with any VB.NET compiler. This sounds like a none-issue and would perhaps be best suited to a presentation setting within the IDE.
With so much reference material in-place using proper-case why change to lowercase? Make it an IDE presentation option if it makes people feel better!
I personally prefer lowercase, but I think it could be dangerous to change it.
As previously mentioned, it could end up with competition between people who prefer different styles if you make it optional (not necessarily concious, but if one person checks in code that’s been formatted to lowercase as per their IDE preferences, and then someone else checks it out and back in with a different casing you would get inconsistencies, though one would hope casing would be standardized on a project).
Even if you make it a compulsory change you would get a large inconsistency between old and new code.
Pingback from http://oakleafblog.blogspot.com/2007/07/new-linq-with-visual-basic-articles.html with off-topic commentary on this topic.
Having the option would be cool. I don’t care a little bit about VB looking like C#, but given all the pascal case in names, if every keyword is lower case, code actually a little bit more readable to me.
I am OK with an option for lower case in itself.
What I am afraid is that following the persistent trend of bastardizing VB and transforming it to a another C surrogate, the option in next version (eventually checked by default) means the only option in the second version from now, opening the way to case senzitivity to variables or function names and so on.
After vb6 release, all the changes in vb (at least perceived by me) were to get it to C syntax and spirit. The whole VB spell was trashed back then.
Now we are already pretty close to C (when I see these a+=1 I fill embarassed that I still am in VB boat).
It is like cutting the tail of a dog inch by inch. Why not simply kill vb completely ? It stinks anyway – doesn’t it ? 😉
Such a shame that developers working in C(++/#) seem to have no respect for the users of the language they develop. Wherever a decision was to be made in developing vb.net I feel that the C guys won, infecting Basic syntax and spirit with alien "assemblish" ghost of C.
I like to some degree .net (except for the IDE performance) and use it BUT from the first .NET beta I played with I somehow regret the easy decision of using and investing in MS Visual Basic 1 back in 1993.
It is not about learning new things – it is about 100s of thousands of lines of code developed with the belief that MS is carring for compatibility the way as it does developing Windows.
The way VB developers were treated when moving to .NET will always remain as a bad memory. I will always advice anyone to think twice and try to avoid nice new shining technologies even with more effort.
Again, the option for all lower case for keywords is OK IMO. What VB became as a whole is not. But than again, this is just my personal opinion 😉
To make VB less verbose, you can make the If/Function/Sub/Case keyword optional in their relative End statements, as well as the Then on multiple-line If
Private Function ParseSimpleNameExpression() As SimpleNameExpression
Dim start As Token = Peek()
Dim name As SimpleName = ParseSimpleName(False)
Dim typeArguments As TypeArgumentCollection = Nothing
If Peek().Type = TokenType.LeftParenthesis
Dim leftParenthesis As Token = Read()
If Peek().Type = TokenType.Of typeArguments = ParseTypeArguments(leftParenthesis, False)
Else
Backtrack(leftParenthesis)
End
End
Return New SimpleNameExpression(name, typeArguments, SpanFrom(start))
End
The "old" End statement should be made forbidden as a way to quit the program.
Indentation was eaten in my previous comment.
As for the lowercase keywords: make it only a visualization options as others have suggested.
I like the current proper case better than the lower-case. Although, making this an option would be the best, becuase I can understand how people would like lower case better.
Look, if you’re worried about how terse the language is, you’re shooting the wrong target. You should be addressing keywords that are spelling out things that the compiler (and the developer) can already tell because the syntax OBVIATES them.
#1. Get rid of the AS keyword.
Variable names can’t have spaces in them. So it follows that whatever comes after the variable name is a data type. The As keyword is completely superfluous. It’s just eye candy. The following is more than enough for a compiler and a developer:
Dim x Integer
Dim lastName String
Dim dateOfBirth Date
#2. Eliminate "End If", "End Case", "End Sub," and "End Function," and all their variants.
This has been covered eloquently by others above.
#3. Get Rid of the Sub and Function keywords.
A method’s type should be obvious based on whether or not the developer has defined a return type for it. For example:
Public Foo(ByVal connection IDbConnection) Boolean
‘ Do something
End ‘ Assuming we got rid of "End Sub"
Essentially, anything that the compiler or the developer can *reasonabily* determine, drop or make optional. Thus, you get something quite terse, like this:
Namespace Foo
Public Main(ByVal arg String)
Console.WriteLine(Baz(arg))
End
Private Baz(ByVal arg String) String
Return String.ToLower()
End
End
Now it’s terse.
Who says terseness is a good thing? If I wanted terse code, I’d use C# (or APL). I like VB code because it’s relatively self-describing.
I personally like the End [If|For|Case] construct, for the reasons listed above. As for lowercase keywords, I like it better the way it is now. It’s a better match for the Framework type casing IMO.
Personaly since moving to dot net I have onyl ever coded the dot net way with lowercase
Dim someObject As SomeObject
It makes code readability so much better especialy now the editor is clever enough to keep the case of variables seperate from those of object types.
Then theres the question of private member variables. _someObject vs mSomeObject. I go with the underscore.
Also what abound vb modules, anyone still use these things in vb.net? Never used them in vb.net. I just use static clases with shared members.
I also never use Integer/Longs etc, I prefer to use Int32,Int64 etc. shorter and far more descriptive. The only downside it there not coloured blue in the editor.
Oh and one last thing, Mike Hofer, is spot on, you could also lose the ByVal , if you need ByRef params then explicity specify ByRef. It’s never going to happen but we can wish.
I’d have moved to C# if it wasn’t for the poor IDE experience compared to VB, + I hate those awful semi-colons 😉
It’s weird: it actually looks ‘shorter’ to me with lower-case keywords – maybe I’ve been corrupted by doing a lot of coding in C# recently.
It definitely looks ‘geekier’ to me as Pradeep said – that’s good from a job security point of view, but probably not in the spirit of VB…
I think I have a marginal preference for lower-case keywords, but it’s not based on anything ‘real’ – it’s probably not worth making it an option, and it would be too drastic to enforce the change.
Have the VB code be proper-cased makes it easier to scan the code. All-lower case might be easier to write, but it is harder to scan when you need to find something.
This is more important than it might seem at first thought.
I have to agree with Christopher and others in favor of keeping the casing as is… I don’t see any benefit and think it actually takes away from readability.
Instead of changing the casing, I would rather see more advanced formatting options like in C# (IDE) for spacing between different language elements.
Roger Jennings said everything I wanted to say, although an option would be nice.
I assume you bootlegged the lexer inside Visual Studio, because the current command-line compiler happily compiles both versions.
I like the lower case syntax.
I think you should make it an optional setting. That way people can go with their preference.
Hi,
1. I think you should make lowercase an optional setting. (Better still is capitalize first letter in If, Case, For as in nomal sentences but not the other:
If some logic then
doSomething
else
doSomethingElse
end if
2. Suggestion to improve readability,:
Get rid of DIM and AS so this can be legal code: "Int32 i = someIntegerValue"
3 Suggestion to improve readability: An optional setting so someArray[indexInteger] is legal besides someArray(ndexInteger), which today can be mixed up with someSub(someVariable)
4 "End if" , "End case", "End sub" etc are great, improves readability significantly! Keep it!
The thing I like most about the way it is now is that it provides a check when I enter variables and keywords in all lower case. When I enter the correct spelling the case corrects itself and I know it is right if everything was in lower case I would spend a great deal of time searching for spelling errors when I typed the code.
I found this lowercase keywords? discussion by Paul Vick to be very interesting…
http://www.xtremevbtalk.com/showthread.php?t=286248
VB’s got much bigger problems than lower casing the keywords. Like to know what would make it look more like C# – CURLY BRACES
@Roger Wagner: IMO, this will only happen until your eyes get used to checking for red squiggly lines under the text.
There is a patch that fixes all of these problems. It’s made by CodeGear and is called "Delphi". 😉
Proper casing has in studies been consistently proven to be more readable. Why consider subjecting us to harder to read code just because the C# guys can’t be bothered to press the shift key from time to time?
I Agree Mike. Proper Case All The Way. It Simply Looks Better, Reads Easier, And Sounds More Memorable.
I would hate to see almost all of the suggestions listed here implemented.
But this does illustrate how varied people’s personal prefrences are. If anything were to be implemented to reduce verbosity, I would hope a ‘reformatter’ function would be included si I could reconstruct someone’s else’s chopped up mess.
One thing to keep in mind is how these options (different casing, spacing between elements, tabs/spaces, etc) is how it affects source control and seeing how the code changes over time. If you have one developer with different settings than the rest of your team then using text diff tools becomes futile as every line in the code file will be different because of different casing, spacing, etc.
Am I the only person to work with option
"Pretty listing (reformatting) of code"
disabled?
I’ve had this disabled for so long, that it never occured to me that keywords could not be all lower case. But, this brings me to another point. The pretty listing ability of VB continues to be pathetic. I hate the reformatting that it performs, in particular, because I like to line up Dim statements in vertical columns. On the other hand, I would like VB to fix the case of variable names. The pretty listing option is all-or-nothing, so I choose nothing, but I would like to be able to pick and choose the options, or even configure them.
By the way, VB6 lets you line up the As in Dim statements, without reformatting it, but vb.net lost this feature.
I’m all about options! That’s why I like VB.NET. If you can give me an option in the IDE to lowercase the keywords then I’m cool with that. The idea I REALLY like is Bill McCarthy’s where you could define the casing/color etc. for key words.
This would be great when I’m looking through a long section of code that may have an If..Then, a Select Case and a Loop and I need to quickly identify where they each end. If I could define If statements as red, Select as greem and Loop as purple it would make it much easier for me to scan a page for a color than to skim each line for text.
I say leave the Proper Casing as it is. It has always been that way, and all the huge base of sample code in both classing and .NET style VB uses the Proper Case form — why change it?
The quality of your code is far more important than whether it appears more verbose because of some little quirk in human visual perception.
As for removing the If/Sub/Select… etc. from the End keyword, I think this would be more trouble than it’s worth. You’d have to add comments to help you remember at the end what you were End’ing, especially when you have several stacked up vertically as in some of the proposed code samples in this thread. Someone pointed out that keeping those keywords helps readability, and I agree completely. Readable code is crucial in maintaining and troubleshooting. Read "Code Complete" by Steve McConnell.
The other point about version control and text file differences is also a good one,particularly in a team development setting. At one place I worked, Source Safe caught as "differences" many cases (no pun intended) where one developer changed the case of SQL keywords in some SQL Server scripts. Functionally it was the same.
I suppose you could put an option in the IDE to control how it is presented in the code editor, as long as it is actually saved in Proper Case format, so that it remains consistent. Keep in mind that any of these "code beautifying" features just add to the number of things going on in an already sluggish IDE.
My $0.02 worth.
I really dont care, uppercase or lowercase… but whatever you do DONT MAKE IT CASE SENSATIVE!
Case sensativity in a programming language has always seemed backwards to me. If is the same as if is the same as IF is the same as iF
Is it just me or is it harder to read all lower case, a bit like a page of text without sentence punctuation, or paragraphing?
Don’t fix wat isn’t broken.
One interesting possibility that Roger Jennings comment inadvertently bought to my mind is to make it purely a cosmetic change in the editor.
When the file is saved (whatever the casing settings are), upper-casing is used. However, if you load the file and have the preferences set to lower case it will be rendered as lower-case. This should solve mine and others anxieties about conflicts and religious wars. To be honest, this could be extended to most of the cosmetic aspects, such as bracing positioning in C# and others.
This does come with it’s own problems though, inherent in that what the user is seeing isn’t actually what they are saving. But I think these are minimal.
Actual implications aside, it does seem to be a very interesting experiment and suffers from the age old "it’s what your used to". Though I have to say lower case keywords actually closer reflect the casing proportions in the English language, presumably making those not used to VB feel more comfortable and thus making scannability for newcomers better. As to what is more effective after training remains debatable though.