Related
I like to use keyword where, for example.
I simply do it like this
Dim orderFromThisGridTrading = _orders1.Where(Function(x) x.customIdentifier = ASimpleGridTradeSettings.name).ToArray
However, most samples would say I have to use from
Dim customersForRegion = From cust In customers Where cust.Region = region
Which is weird af and don't follow normal vb.net format. That looks a like like SQL languages and not a real programming language.
I wonder if I can always avoid using Form and just use like I am using? Are there any cases where that is not possible?
Is this even a good idea?
There is nothing bad in using query syntax in general. Especially in VB.NET it is very powerful and supports a lot of LINQ methods(more than in C#). Many prefer that because it can make your code more readable. But it seems that the opposite is true for you, you don't like it. Then use the method syntax, it supports all methods. I don't like it in VB.NET because of that ugly and verbose Function keyword, especially with GroupBy or Join i prefer query syntax.
I wonder if I can always avoid using From and just use like I am
using? Are there any cases where that is not possible?
No, method syntax is always possible. Actually query syntax gets compiled to method syntax.
The second example is called "Query Comprehension Syntax". It's optional. A lot of people find it makes their code more readable, but not everyone likes it. Personally, I find it adds another extra layer of indirection for what you need to know to get the computer to do what you want.
In the first example, the "From" is implied by the intial IEnumerable or IQueryable item in the expression.
But I do have one issue:
SQL is definitely a real programming language, and you'll likely get even better results from learning it well vs needing to rely on an ORM to construct queries. Eventually, usually sooner than later, you'll find you want to do something where you need to know advanced SQL anyway. Then you have two problems, because you need to the know the SQL and you need to know how to construct the ORM syntax to produce that SQL.
I'm a seasoned programmer and therefore feel a little embarrassed asking this question but decided to do so anyways.
I'm reading this book, and have also seen various examples across the net where the order of arguments in a compare operation is reversed and I wonder if there is a reason for it, or just because it looks "cool" and does the exact same thing.
Example:
I would code:
if(bool_variable == YES)
while I saw in this book and in various examples
if(YES == bool_variable)
Explanations?
Thanks a ton!
Some people like yoda conditions because they can help you find errors where you accidentally type = instead of ==. For example:
if (var = YES)
will compile but probably not work the way you want it to. Writing it the other way around:
if (YES = var)
will cause a compile-time error. I personally dislike this construct, but to each his own, I guess.
Carl's got it -- a programmer who puts a constant on the left side will be protected by the compiler.
I just wanted to add that perhaps one of the reasons people switch them around is that one or one's employer may have code style guidelines that specify which side the constant should be on, but of course this just lends itself to the safety net of syntax errors.
I personally have always put the constant on the ride hand side for readability, but to each his/her own.
Have there been any cases where you wanted to use a word as a variable/function name, but couldn't because it was a reserved word in your language?
The ones that crop up over and over again for me are in and out in C#... Those would be great names for streams, but I'm always forced to use inn and outt instead.
EDIT: I'm not asking about help with this problem -- I'm trying to learn from mistakes that past language designers have made. Your answers will influence a language I'm designing.
type and object. I don't like when my programming languages steal those :(
Some languages let you use any words you want anywhere. Clojure, for example:
(let [let "what?"] let)
=> "what?"
This could either be helpful or horrible depending on the context.
I like to use new and delete as function pointer fields in OO-ish C code a lot, which makes porting to C++ "fun"... ugh.
This isn't really a problem for C#, though:
int #in;
There, now you have a variable named in.
No, not really. Keywords in a language tend to be short and general - two things that rarely make for good variable names.
In those cases, I think of "in" and "out" as adjectives, and usually make something more descriptive, such as "inStream" and "outStream".
Can anyone make really a good case ( :-) ) for being case sensitive?
C#: case sensitive
VB.NET: not case sensitive
C++: case sensitive
...
Worse part: XML which is used inside a language like VB.NET is case sensitive.
I was making the case that it is ridiculous and can only cause harm after we found a bug in our system due to the fact that XML had both Value and value nodes...
I am asked over and over in comments
"Perhaps you can come up with a single
argument for why case insensitive is
the right choice in such a world?"
Here is an example:
I see it analogous to the issue of: URL's should be case sensitive?
www.cnn.com <> Www.cNN.com ?
Of course they should be the same, ID theft heaven! because humans don't put that much attention to 2 strings that are the same but might have otherwise different casing. Programmers are humans. So getAge() and getage() are the same in most human's minds.
Please notice: I do not think we want the code to actually have a function defined as getAget() and then have code calling it getage(), VS (vb.net) will automatically correct getaget to getAge. So the code is clear and the programmer is aware of the correct capitalization. My point is: good IDE makes the issue non relevant, but it works better in a non case-sesnsetive language like vb.net then lets say c#.
Reference: here
Case rules depend on culture. Do you want a programming language where a variable i is sometimes considered to be the same as one called I and sometimes they're different variables? (That's not a made-up example, btw. In Turkish, I is not an upper-case i.
Honestly, it's pretty simple. Do you want the compiler to correct you when you make a typo, or do you want it to guess at what you meant? The latter leads to bugs, as you found out. VB assumes "oh, you probably meant the same thing, that's ok, we won't stop you", and XML took you literally.
Your bug didn't occur because case sensitivity is bad, it occurred because being sloppy is bad. Arbitrarily changing case may, at best, cause no problems, and at worst it will cause errors. Assume the worst, and be consistent with your case. Which, incidentally, is what case sensitive languages force you to do. Whether or not your tools are case sensitive, the programmer should be case sensitive. Being case sensitive saves you a lot of trouble as long as the world features insensitive as well as sensitive tools. If we could remake the world so that everything was case insensitive, a lot of the reasons in favor of sensitivity would go away. but we can't.
A little side note of course:
In many languages, it is common to give variables and types the same names, but with different capitalization:
Foo foo; // declare a variable foo of type Foo
Of course you could argue that "you shouldn't do that", but it's convenient, and it immediately tells the reader what type the variable has. It allows us to create a Log class, and a log object. And since the purpose of this object is to log, the name is kinda obvious.
And a final point to consider:
Case matters in real languages. A word that begins with upper-case is different from the same one but with leading lower-case. The word "worD" is not correct english. Information is encoded in the case, which makes text easier to read. It tells us when we encounter a name, for example, or when a sentence begins, which is handy. Allowing people to ignore case rules makes text harder to read. And since code should generally be written as readable as possible, why shouldn't we do the same in programming? Allow the case to encode important information. In many languages, Foo is a type, and foo is a variable. That's important information. I want to know this when I program. If I see a function called "Getage", I wonder if that's some English word I've never heard before. But when I see "GetAge", I immediately know that it should be read as the word "Get" followed by the word "Age".
By the way, here's a nice example of the fun surprises you can run into in case sensitive languages.
Slop is never a good idea in a programming language. You want things to be as specific as possible. You never want your language to guess at anything and it should allow as few ways to solve a given problem as possible.
As for a specific answer, how about readability? Doesn't stoRetroData visually differ quite a bit from storeTRodAtA? Not that anyone would do such a thing, but what's the point in allowing it?
I can't come up with any reason to allow ignoring case.
At least that's my opinion--but your mileage may vary.
Edit: I probably should have started this out with a disclaimer:
I learned to program in basic and had this same thought fleetingly about 18 years ago. Trust me, it's one of those things you'll look back on in 20 years and go "Oh, yeah, I was pretty wrong about that" (as I am right now)
History It is the way it has been done. The XML is VB.NET is case sensitive because the XML standard requires it
Internationalization Are we going to support case in all languages (French, Japanese, Hebrew, Klingon, etc.)?
Several case sensitive languages nowadays are that way because the languages they were based on were case sensitive and the transition would be easier. Personally I prefer case sensitive, but Jeff Atwood wrote a pretty good article on why case sensitivity may no longer be necessary.
Couple of reasons.
Finding things, with case-insensitive I'd have to have 'case-insensitive' flag about everywhere. With UTF-8 that should be also aware of Klingon smallcase..
More importaintly, CamelCasing, CAMelcaSing. It's not pretty, but it's used a lot and is fairly sane. Is nigh impossible with case-insensitivity.
Language parity, for example xsd.exe (shipped with VS200x) can generate you classes for xsd that you supply. What would be your "Value" named when you also have "value"? So this takes out yet another possible impedance.
Case is good in programming languages, but rather than use it in symbol names we should use it as it was originally intended- to delimit the beginning of a sentence or command or a proper name. For example:
Var test = 0;
Console.writeline(test);
Test = test + 1;
Console.writeline(test);
So beautiful,... :P
I find case-insensitivity to be just silly. You should follow the capitalization of the original declaration. I can't see any good reasons for not doing so beside being too lazy to type TheRealName instead of therealname.
In fact, I would never even consider using a case-insensitive language.
Do languages become more verbose as they mature? It feels like each new version of VB.net gains more syntax. Is it possible to trim down some fat like the keyword "Dim"? C# also feels like it is getting more syntax since version 1.
C# has certainly gained more syntax, but in a way which makes it less verbose.
Virtually every feature in C# 3.0 allows you to do more with less code.
That's the VB idiom. All languages have an idiom, and there are plenty that go for verbose and spelled-out. Thank your lucky stars you're not WRITING IN COBOL.
C# evolved out of the C-like languages, and in the C tradition brevity and terseness are valued, hence braces, && and ||, int not integer, case-sensitive lower-cased code. In the VB idiom, long self-explanatory keywords are good, terse keywords or cryptic symbols are bad, hence MustInherit, Dim blah as Integer and case insensitivity but with a tendency to Capitalise Your Keywords. Basically, stick with the idiom of the language you're using. If you use (or have to use) VB, then get used to the verbosity - it's intentional.
There's nothing wrong with verbosity, in fact it often can be a very good thing.
I assume you have meaningful variable names? Descriptive method names? Then why is there a problem with typing 'end if' instead of '}'. Its really not an issue at all, if anything, the terseness of C# is more of a problem trying to fit as much as possible into as few characters as possible - that means it harder to read, not easier.
Okay... this feels embarrassing to admit, but I like the use of Dim in VB.NET. Yes, it's not serving any particular use that couldn't be inferred by the use of "As" later... but to me, there's something absolutely "beat you over the head" obvious about having declaration statements start with Dim. It means when someone's looking through the code, they don't even have to think about what those statements mean, even for a microsecond. Languages like C# have declarations that are obvious enough, but if you're just browsing by it you may have to consider it for a moment (even the most brief of moments).
There's something "extra obvious" about having a special keyword at the start of certain kinds of statements. In VB.NET, assignments start with "Dim" and calls to methods (can) start with "Call", giving them a kind of "left side uniformity" that If, For, and other constructs already have: you get the barest gist of what's going on with that line just by looking at the very start of it. Using these almost gives you the equivalent of a left-hand column that you can browse down extremely quickly and get the gist of what's going on on some kind of basic level ("Okay, we're declaring things here... we're calling to other things here...").
That might seem irrational or even silly to some people... but it does make the purpose of each statement explicit enough that it feels faster (at least to me) to browse through... especially when browsing through unfamiliar code written by others.
I guess, in the end, it comes down to "different strokes for different folks". I don't mind typing the extra three characters for that obviousness of purpose.
VB.NET is great as it is, it brings more clarity in code.
For instance I love the fact how you can describe what your ending.
End while vs }
End for vs }
End if vs }
And really the verbosity isn't an issue while typing because of intellisence.
Verbosity and readability often go hand-in-hand. Lately I've come to fear the word "Elegant", because it generally translates into "Fun but less immediately readable"
Of course the person writing the code always says "Well it's MORE readable to me because it's shorter/more elegant.
that's crap. It's always easier to read something more explicit unless you have so much trouble reading that it takes you two hours to get through a Dick and Jane novel.
Note that I'm not talking about redundancies, just being explicit and spelling out your desires.
As a programmer it's much MUCH more fun to write elegant expressions, but I've found myself looking at the "elegance" of others and even my own "elegance" after a while and I'll change it to something more explicit, readable and reliable when I realize that although it was fun to write, I just spent more time reading/debugging it than it took to write in the first place.
On the other hand, DIM is just stupid :)
I'm slightly out of my depth here.
I like what everyone calls verbose. Does no one ever wonder my we don't have multiple nested parenthesis in any natural languages (e.g. English)? In fact nested parenthesis really need the convention of indentation to make then legible at all. In natural languages we use verbose clauses and multiple sentences, to avoid, or at least explain layering parenthesis.
Also in a certain sense I wouldn't say vb has much more syntax than c# at all. It doesn't really have many more lexical tokens in a certain block of code than would c# (Does it?). It has about the same syntax as c# it just has longer syntactical tokens, 'End Sub' instead of '}' for example. For most pieces of syntactical plumbing, the VB version will just be more typing (if you are sworn off intelisense), Also '}' is ambiguous compared to 'End Sub' since it also means 'End If' and whole load of other things. This doesn't make it more concise in a certain sense, There are still the same number of tokens in the code, but from a smaller subset of more curt token markers. But different tokens in C# have different meanings depending on the context, which requires you still to have that nested level in your mind as you read the code, in order to get, for example what kind of code block you are reading if you lose your place, even though the end of the code block could be in view you might have to look up to see the beginning of the code block. Even where this is not the case is && really better than AndAlso?
Dim I suppose is quite useless, an extra lexical token compared to c#, but I suppose at least it's consistent with linq, vb doesn't need the var command. I can't think of any other candidates for the chop. Maybe I don't have the imagination.
I'm sure someone is going to come along and tell me how wrong I am :) My best guess this is to do with personal preference anyway.
Then C# should get rid of ";" at the end of every fricking line :)
Default should be easy way to go such "New Line" instead of a ";" if you want exceptions such 2 statements in the same line then you need use a separator such as ":" or ";"
Some people like that. I suspect things like Dim are left in for legacy reasons as much as anything else.
VB does have some nice short cuts though. For example the conversion routines. Eg CInt, CStr etc
OK I'm an old C programmer that came to .Net via C#, and Now I'm working in VB.Net
I have to say at first I was appalled by the verbosity, but having gone back to
C# for I bit, I have to admit I like VB.Net a bit more now.
I can write VB code that reads better and is less cryptic and it really doesn't take
up much more space (especially if you put all your C# curly braces on their own line)
Also the editor in Visual Studio takes care of most of the verbosity for me.
I like how Dim X As List(Of SomeType) reads as opposed to List<sometype> X
Semi-colons are a nuisance now. Curly braces are annoying.
I do miss the square brackets for array refs, a little bit though.
Ever since I saw this...
lowercase keywords?
...I've been hoping it would get included in the language. It's amazing how much more readable it is Without All The Capitalized Keywords.
C# is not a user-friendly language and takes many MORE lines of code to accomplish the same task as VB.Net. Optional parameters, with/end with, etc. are not supported within C#. Even db connections take more code in C#. Star Wars fans love the C# though, as you get to talk like Yoda while you're programming.
My $0.02: VB.Net's intellisense features, shortcuts, logical readability, etc. make it a superior language.
Yes I know what you mean, it can get a bit long winded, I find it becomes hard to read due to there being to too many keywords and making it hard to see the logic behind it all but hey some people like it.
I have just recently started writing all my stuff in C# and I must say I have come to like it a lot more since I just cut of VB and said right C# from now on, so if you are that worried your could always just switch.
Use a pre-processor... and loose any hope to be read by anybody else (or yourself in some years, perhaps...).
I will answer what is often answered to people complaining that Lua is verbose: if you want a concise language, you know where to find it. There are tons of languages around, even if you restrict yourself to the CLR, so why complain about the one you chose? (I know, you might work on a project you didn't started, etc.).
That's not a flame or something. There are many languages for a reason. Some like them super-concise, close of mathematical notations, others like them (more or less) verbose, finding that more readable. There are languages for all tastes!
for one thing that i don't like about VB is this
print("ByVal sender as object, ByVal e as EventArgs");
vs C#
object sender, Eventargs e
Doing so will only make your code harder to read.