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.
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 10 years ago.
You and me both know that creating a document for codes is really boring and i opened this as a discussion that you share your experience for creating document for your code.
i think project documentation is differs from code documentation in a project documentation you can use UML to describe the whole projects,algorithms,designs, architecture.However your code documentation is very effective while your developing a DLL library or providing a web service or any other codes that will be use from other developers.
i think discussion subjects is :
1.Tools that you know useful for generating documentation
2.Methods and Rules for providing a source documentation
3.Does other developer code comment helped you what was useful
This is one of those things that the community in general tends to disagree on. Not in general... I think we all acknowledge that code documentation is A Good Thing™, but how we do it is a personal matter.
Here is my take on it:
I know it's painful, but inline documentation helps to keep you focused, as well as giving you some information you can refer to when you look back at the code.
1) I use Sandcastle to generate help files from my libraries, which I document with XML document comments.
2a) Always provide reasonable XML documentation for your public fields, properties and methods. Don't just put /// <summary>FieldName</summary>, describe what the field is for.
2b) Use inline comments sparingly. Don't comment every line, but do comment blocks of code that do something interesting or in an interesting way, just so you (or anyone else) can understand it clearly next time you read the code.
3) Abso-freaking-lutely. Reading my own code is usually pretty simple, but every developer works differently. When you have a piece of code somebody else wrote, comments can make the difference between understanding and not.
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.
I especially hope to understand the principle that drives you to use it despite that it is not efficient. Correct me if what I say is not true.
Another way of looking at this question can be why should we use it and why not? Is Reflection a good way of programmation?
Thank you.
http://csharp.net-tutorials.com/reflection/introduction/
http://www.csharp-examples.net/reflection-examples/
http://www.codeproject.com/Articles/17269/Reflection-in-C-Tutorial
http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257
I'm not being arrogant by posting these links - I just think with a few mins of 'googling' you'll have the same explanation you're waiting for here anyway.
.NET Perspective
Many frameworks within the .NET framework will stop working without reflection. ASP.NET MVC is purely working on reflection.
It is powerful but the power comes with responsibility. Reflection is slow, so you need to be sure what you are doing.
Reflection gives un enormous benefits in architecturing the software.
For example plug-in base systems are almost unthinkable to be developed without heavy use of it.
It's very powerful (and in .NET very performant) feature that let's you read/write the data at runtime in dynamic and generic way.
reflection is a good technology. But its a heavy weight thing. And dont just go about using reflection every where just beacuse you learned how to use it. Use it only where really necessary.
Hope this PPT helps you learn:
http://www.slideshare.net/rohitvipin/reflection-power-pointpresentation-ppt
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.
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".