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".
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 9 years ago.
I'm working on enhancing the platforms in my company and during my research, I've come across a lot of comments from people saying that ArrayLists should be avoided. However, they never gave much explanation why and I can't find any articles about why they're so awful.
"Arraylists" (also sometimes called "vectors") are perfectly fine data structures; it's just that ArrayList is a class that should be avoided in C#.
The reason is that it isn't generic, so you can store any object inside it, breaking type-safety.
Use List<T> instead.
Because they're not strongly typed. They're a bag that can store anything. That means you have to cast when retrieving elements. It also means that there may or may not be boxing/unboxing involved in storing and retrieving values.
They're not generic. A List is exactly the same thing, but it's generic. This means you're ensuring the objects are all of a common type, and that constraint is enforced by the compiler. It also avoids boxing of value types.
It's not so much awful as painful. Think of them as List, sort of, ish.
So you have to add a lots of rules to enforce consistency in the collection and use them "everywhere" or deal with the errors that result from having no consistency,"everywhere"
So that a lot of extra code, or you cross your fingers real tight and hope no "dimwit" programmer ever puts something in there you can't deal with.
If your collection could consist of anything, then stick with it, though personally I'd say that if it did, there's almost certainly some sort of major design flaw.
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 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.
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.