As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
After reading this old post from Clinton Begin (creator of iBatis) I really wonder if his claims about annotations vs. attributes are widely accepted or if there is disagreement about it.
His points are:
Annotations are not extendable
No support for positional arguments
Java-unlike definition syntax
annotation is not a keyword (unlike enum)
Do those claims have merit and how does C# improve on that?
Well taken one by one those points obviously have merit:
Attributes are classes you can extend and query as you wish. You can even add your own!
Position arguments (I'm guessing you mean named arguments) are indeed possible with C#, with full Intellisense support.
Can't really comment on how weird it looks, although coming from Razor it makes me think of macro expansion.
Attributes don't have a keyword either, they're just a normal class.
That doesn't make Java's implementation worse, since they had a different goal in mind: backwards compatibility. C# had the advantage of building the language from scratch (and then progressing forward instead of maintaining strict backwards compatibility).
As a nit-pick though, nothing you or I mentioned are part of C#, they are part of the .NET runtime and can be found equally well in VB.NET and F#.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is the first time I go into actually trying to implement a Domain Specific Language.
I know the basics of language grammars and Abstract Syntax Trees, however I didn't get my hands dirty in implementing them before.
I want to build a small language, simple variables/arrays and conditional statements. I want to interpret and execute the user entered code via an interpreter I build by C#. Something pretty similar in spirit to PHP tho way simpler.
I searched and I became confused.
Best parser generators I found which had good C# supports were Gold and Irony. I also found ANTLR but I saw too many people complaining about problems with C# suppots. Also, the three of those seem to lack good documentation.
My main fear is to begin working with one of them and then discovering its not usable for the task, either because of lack of good C# support, or good documentation or something else. I want something that I can begin working with "confidently" to get myself kickstarted in the project.
Could anyone help me to pick something that does the job well and guaranteed to work well with C# ?
I suggest you to use ANTLR. I wrote my own compiler (for MSIL) using it.
ANTLR has C# support and i did not found any problems with it.
U can also look at my source code (i can not be working sample, but it has ANTLT .g file) for sample.
I suggest you try TinyPG. It compiles to C#, and you can provide C# directly in the grammar.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So far I understand that its good practice to XML comment a classes methods but is there a standard for how much you should use XML comments?
Should I be using them to document field variables, properties & constructors or is that just overkill?
Had a look about the web but can't see any hard and fast rules for this sort of thing.
There are two reason to use XML comments opposed to plain English:
If the comments follow the correct format they will show up in IntelliSense, meaning when I use your class I can see that int a is supposed to be the count or whatever the same way I see helpful info when I'm using .NET methods,
If you use the XML formats Microsoft supports you can create html (or other formats of) documentation using SandCastle or similar third party utilities.
So, if you're taking the time to write comments, you may as well make them the XML ones that VS encourages.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Please let me know the difference between C#.Net and VB.Net. I use C#.Net for my projects, but when ever I met with some other programmers they often called VB.Net more powerful and easy, than C#.Net. I always asked them "Why it is more powerful then C#, since it uses the same framework?" but still I didn't get any helpful answers.
Pointers (C#)
XML literals (VB.NET)
VB6 leftovers (VB.NET)
A few other syntax differences
In the end, not a whole lot. Although, some say C# programmers are better paid (never looked into it, but it's possible).
It also depends on your definition of 'powerful' and 'easy'. Both are powerful at their jobs. C# may have a slight advantage in terms of performance since it has pointers.. but they are rarely used in most cases.
Technically, there is no difference except the syntax. Both use the Common Language Runtime (wikipedia) (msdn). They are just two different languages that use the same libraries, and actually compile to the same thing. This is one of the reasons you can write a library in VB.net, compile it to a dll, and include that dll in a c# program.
There are some small differences, but for the most part, the choice of one over the other is almost entirely personal preference. Personally, I find the c# syntax to be less prone to errors, but some people like the "english-ness" of VB.
It's the same thing. I don't even know why Microsoft have C# and VB since it really does the same things.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Update: Thanks for closing my question because it might solicit opinions or discussion. That was the point as spelled out by the disclaimer below. Will someone please reopen this?
Disclaimer:
For starters, I realize how this question and possible answer isn't very black and white, but I am at an impasse and I need some different points of view.
Question:
When I am working in WPF, I often use the MVVM pattern to make things happen. In any given program I will have a bunch of View Model classes that all derive from a class called 'ViewModelBase' and it has been my habit to suffix the class names with 'ViewModel' However I am finding that I wind up with a lot of classes that have very long names such as...
InputDataViewModel
CalculationsViewModel
and so on. I like that they have some context in their name, but they can be a bit cumbersome when it comes to generic programming, etc. I am beginning to come to the opinion that the fact that they all derive from 'ViewModelBase' is enough information to identify them as view models and so the suffix on the names is becoming more trouble than it's worth.
Does anyone else have a similar experience or insight to offer on this issue? Pros, cons, etc?
Also:
No, I am not using an MVVM framework like caliburn, MVVMLight or anything like that.
Assuming that you are using a good IDE, like Visual Studio, you really don't need to add ViewModel. This is because Visual Studio's intellisense makes it easy to see what a class derives from, the methods it supports, etc. The benefit of adding the suffix is that people who don't use a fancy IDE will still be able to work with your code.
Also, you might have other classes that involve Calculations. Adding a unique suffix to each class name makes it easier when you or another developer is quickly scanning over your code. Without the suffix, it may require a further lookup in another file to determine what a class does.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
visual basic.net is case insensitive so it allows the coder to write without caring or remembering the casing of variables. it also relieves from the 'undeclared variable' errors if you use the variable in another case than the one used in declaration. The fact that its line termination is a line feed makes it even more readable unlike C# or c++ that need good care in the casing and contineous war with following up with the {}, matching them and figuring out which is for which.
my question is what are the advantages of c# over vb knowing that both get compiled to MSIL so there is almost no performance difference between the two languages?
In the case of Visual Basic and C#. There is no real performance difference. But I know a lot of people, and I can conclude that people prefer C# when they learned the language C/C++ first. And people prefer Visual Basic when they learned Pascal First. It's just the syntax.