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.
I was reading this post and it left me wondering...
Why is it wrong to use a variable named _ in C# for a intensively used library (should one ever surface), but perfectly fine to use $ for the same purpose under JavaScript?
Arguably because _ (as a variable name by itself) carries no meaning, and a longer/more meaningful identifier doesn't take much longer to type (with Visual Studio's intellisense). Not to mention the fact that the C# compiler won't "penalize" you (in terms of increasing the size of your compiled program) for having a longer identifier.
In the case of jQuery, however, using someIdentifier instead of $ actually does increase the final size of your javascript file. By a couple of characters, sure -- but multiply that by a couple of orders of magnitude (number times repeated in your file, number of times your file will be downloaded by a client's browser, etc.) and a few characters could start to matter, especially if your site experiences a lot of traffic.
Finally, you also have to take into account the community involved. In the Javascript community, for example, jQuery is so commonplace that even if you don't use it in your application, anyone remotely familiar with it will know what $ means. There's nothing in C# (that I'm aware of) that has that level of visibility, and since it's a compiled language with a powerful IDE, there's really no need for a jQuery-like "$"-equivalent prefix.
My two cents.
Define "perfectly fine". A variable called _ is syntactically valid in C# but, as you may notice one or two (or every single) respondent saying in that question, it avails you very, very little to use a naming convention like that, while rendering your code highly difficult to read.
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.
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.
I have been using the default of new line for methods and code blocks but it's using up a lot of space. Should I use the curly brace on the same line as the start of the method? Is there any disadvantage to doing this?
Disadvantage of putting the opening { on the same line: some people don't like it, and some people find it harder to read.
Disadvantage of putting the opening { on the next line: some people don't like it, and it takes up more vertical space.
I think next line looks prettier, but I don't really find it easier or harder to read assuming the code is indented nicely.
If you are working in a team with standards mandating one or the other then you should follow the standard, otherwise do whichever you prefer.
Yes, in my opinion there is. Simply put, readibility. If not for you, then at least for others. Trust me though, you'll be glad later on that they're on seperate lines.
Edit: Technically, it doesn't matter though.
It's completely up to you. Both have the same meaning to the compiler.
I find it best to stick to an externally defined standard regardless of which code base I am working on. That way the styling standard is portable. In particular, I tend to use StyleCop to govern this, using the default rules as much as possible. In the default StyleCop ruleset, it is stated that the brace should be on the following line.
You can write all the code in one line.. But I think it's more readable when you use the default method.. That's the only disadvantage.
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#.
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.
I and some buddies have an argument here -
in which langauge is it safer by terms of writing a code that cannot be hacked?
by hacked I mean that after the code is encrypted, or turned into executable , it can be reversed enginered into some kind of intermidate code (like java byte code) , or even the real high level program code itself .
This agruments aruse in general because one of us is about to start a big software project,but he's afraid that his competitors will steal some of his very-efficient algorithams.
It would be nice if any of you could present some pros and cons for each langauge .
thanks.
I don't really get to work with Java so I'm more familiar with C#.
In C# (or other .net languages) you can use easy and free tools like Reflector to see ALL of the code written inside an executable or dll.
You can always try obfuscating the code with the most advanced tools, so this won't be revealed easily, but I'm pretty sure that if the code is worth enough for someone to hack/reverse-engineer, It WILL be, and it's just a matter of time till that happens!
Even with lower level languages like C/C++, if the code is worth it, the people interested will find out how it works.
Bottom line : EVERYTHING IS HACKABLE/REVERSE-ENGINEERABLE!
:)
Both Java and C# can be decompiled to (mostly) your original source code. In .Net you have Reflector, in Java you have DJ's Decompiler. It works both ways.
In the end, it doesn't really matter. If someone is determined, they can always dis-assemble your code and still get the "efficient algorithms". Any code readable by the CPU is readable by a human.
Since by "security" you seem to mean protection against reverse-engineering, your best bet is probably native code like C/C++... most interpreted languages are much easier to decompile than native code, although you can obfuscate them to make it harder.
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.
I totally agree that we should not use Hungarian Notation to name variables. But it seems that Hungarian Notation is still useful to name controls (especially Winform controls). Consider these:
GridView grvUsers
TextBox txtPassword
etc...
I really doubt that should we avoid Hungarian notation in this case? If should, which is alternative solution to name controls?
Regardless of whether it is right or wrong, it is still the defacto standard to use Hungarian Notation for naming controls, and it seems very out-of-place not to adopt it. In the same way that methods in .NET languages use Pascal Casing (while in most other languages it is frowned upon), stepping outside of the accepted conventions for the environment you're working in just tends to make your code look even more out-of-place.
I am personally in favour of the practise, as it helps to distinguish class members which are part of the user-interface (view) from those members which are part of the code-behind (model/controller). If the control variables are given similar-looking names to those used to store data, state, etc then I feel as though it is harder to resist the temptation to tightly couple the two. Of course, a more distinct separation of logic would overcome that as well.
Nevertheless, Hungarian Notation leaves no doubt as to which variables are part of the user-interface, and also makes clear as to their type and function, both in the designer and the code editor.
I usually name controls according to what they are, but with more Englishy names. Like, i'll name a label control for a first name box, "FirstNameLabel", and the textbox "FirstNameBox". It wasn't even intentional; i just noticed one day i was doing it, and it made sense to keep doing it.
I think i'm gonna call this "American notation".