I've created quite a few user controls to encapsulate GUI functionality used in multiple places in my app. I've noticed I usually have a tendency to describe the function of the control and tack "Control" on the end of the name, but not always. I'd like to standardize the naming and wanted to know if there's a best practice for naming User Controls in .NET?
Actually, Control is a pretty good suffix. Consider making a control for Name/Address, you want something in the name that marks it as GUI instead of Logical.
So I tend to use NameAddressControl.
I also suffix my user controls with "Control"
My typical structure for UI modules would look something like:
DataEntry
-> DataEntryForm
-> DataEntryAddressControl
-> DataEntryNameControl
-> DataEntryAddressItem
-> DataEntryAddressItemCollection
-> DataEntryConfirmationDialog
etc.
works well for our team
Try to stay with something familiar to the user unless you are coding directly for other coders. It is a proven reliability issue not to introduce nomenclature that end-user is not familiar with.
Like some of the others, we also use the Control suffix for our user controls. (ie ResPayerControl)
UI elements are the only thing that I still do Hungarian notation for. uctDoesSomething works for me.
This is mostly a preference thing but I find that when I'm selecting a control my thoughts go in the order of "what type of control would it be" and then "what does it do". In that case it makes sense to type out "uct" and let intellisense provide me the alternatives.
There are two methods I've seen used:
LoginDateCalendarCtl
UCLoginDateCalendar
firstNameLA.Text="Name:";
firstNameTI.Text="<Enter your name in this TextInput Control>";
1) lowcaseCamel because controls are default private
2) use suffix instead of prefix for intellisense, etc to pick up by name not type
3) include the type and not simply 'Control', to remind your mind of the real, weireded-out names of all those darn fancy-schmantzy ui comps you gots
Related
I'm having trouble finding a site that goes into detail about naming conventions for the common controls of Visual Studio. Either a website or list would be appreciated.
I'm not looking for naming conventions for namespaces, classes, methods, or variables.
I am looking for naming conventions for things like buttons and labels.
Best practices for C# GUI naming conventions?
It seems that this is still something of a theological war with no accepted convention in the wider community.
I typically use a rather simple convention:
_buttonSubmit (ASP:Button Called Submit)
_dropDownYear (ASP:DropDownList for Years)
_placeHolderSomething (ASP:PlaceHolder for something)
Now, winForms, WPF, or ASP.NET, I think it's a good idea to always prefix your name with the control type, so when using it in a code behind, you instantly know what it is.
_radioButtonOne
Without mousing over for intellisense, you can be sure it's a Radio Button, etc. In addition, the '_' in front usually separates it from local variables as an instance specific member.
_radioButtonOne.Checked = true;
someLocalVariable++;
Not quite sure if there is an actuall standard, as lots of developers like to argue pro's and cons on humpback and other notations.
I just finished up my program at fanshawe, and throughout the years they have recommended using hungarian notation.
That being said, here is some exmaples of how we were taught;
lblName - label
txtName - text box
cmbName - combo box
drpName = drop down
Really, you want to associaite the variable name with what the variable actually is.
http://en.wikipedia.org/wiki/Hungarian_notation
I've started using this alot to link elements of my UI to their data backing class (whatever that might be). What are some of the common uses you put the Tag property to use for?
Indeed, do you use it at all? I know I didn't for a very long time.
Just as you describe, the most frequent use of the Tag property I have come across and use in both WinForms, WPF and Silverlight is to indicate the real data that the control relates to. This is especially useful on ListViewItem instances or auto-generated user interface where you want to use the same event handler for multiple objects where only the target data is different (i.e. the action to be performed remains the same).
However, I have also used the Tag to store an enumeration value (though you should avoid value types as it would cause boxing when assigning the value to the Tag property) or a string that is then used to determine the action that needs to be performed instead of the data on which to perform it, and in one particular usage, I stored a delegate so that I could auto-generate some buttons and embed their handlers in the Tag (the handler information was supplied in a data driven manner).
I am sure there are many other ways to use Tag and many other ways to replace the uses of Tag with something more strongly typed, but that's how I've used it.
The Tag property is an ancient (in programming language terms) hold over for controls. To my knowledge, it's been used in everything from visual basic, delphi, and pretty much any other gui based language.
It is simply an extra property that allows you to add a numeric value for any reason you want to the control.
I've seen it used for everything from a counter to holding a record id that the control is tied to.
It is a bit of a kludge. It is often used in for instance a TreeView to link a Node to a data element.
But I would not over-use it, since it is very public and not very flexible. Note that you can almost always use a Dictionary< Control, ValueType> instead, and have a lot more control that way.
I use it all the time with ListViews and TreeViews. It makes trying to find the underlying data much easier. In fact, I'm not sure how you'd make a readable Winforms application without it.
I also use it a lot when creating ContextMenus at run-time. I stuff an object into the Tag member of each ToolStripMenuItem and then I can point each menu item's click handler at the same method. It results in a lot less code.
I just wish it didn't require so much casting.
I'm not too quite sure about what i should do about a grouped set of classes.
My situation: I have 11 classes that relate only to the class Character.cs, but all of those classes (including Character.cs and CharacterManager.cs) are within the namespace Models.Characters.
Which is the more "proper" or preferred way of naming the classes:
(examples):
CharacterDetails.cs
CharacterSprites
CharacterAppearance
CharacterClientRights
CharacterServerRights
or:
Details.cs
Sprites
Appearance
ClientRights
ServerRights
(They're all noticed in Models.Characters (so eg. Models.Characters.CharacterDetails, Models.Characters.Appearance)
Thanks in advance.
Personally for me it"depends". Usually I would prefix everything with the word Character to keep things consistant, however if you have everything already under the Character namespace the Character prefix could seem redundant.
I could easily see going with the shorter convention of Models.Character.[X] if there never will be another class called Details, if there for instance could be UserDetails then Details and UserDetails could be confusing when looking back at the code weeks or months from now and I would personally prefer then the CharacterDetails option.
In the end it is your personal preference, what more accurately describes your domain, Details or CharacterDetails?
Personally I'd stick with the second method as that is what namespaces are for: grouping related sets of classes. The first method is just making the class names longer with negligible benefits.
Your namespace already is grouping its classes under the Characters umbrella, so I would not name your classes with the Character moniker.
There is probably no right or wrong answer here. I find myself prefering your first style, but I have used the second style as well. I think in this specific situation if I were a caller of your API I would find it easier to read code that used the first style.
It is really a personal preference.
I would favor
CharacterDetails
CharacterSprites
CharacterAppearance
CharacterClientRights
CharacterServerRights
Because it is more readable.
You are typically going to have a using statement of
Models.Characters.Appearance
Unless you are going to do the full notation.
I would favor anything that would increase readability. It might matter on the project and the team you are working with. If it is just you than do what you like best and would help you maintain the code in the future.
As long as you pick one and consistantly use that throughtout your code, then whichever one you choose is the right one.
My personal choice is your second option. If your namespace is character, I see no reason to use the prefix character in the class name.
Think about ambiguity that may be created by naming class. For example if I have a class called "Thread" denoting "CharacterThread" (hypothetical) and if some other class uses two namespaces
Models.Characters
System.Diagnostics
I will have to fully qualify the Thread name everytime I use it ... which can be a pain sometimes
i have a design problem.. it may seem that i'm giving you too much details, but those are important.
say i have a very large input form, with a complicated input, that requires quiet complicated validations, includes validations of relations between different inputs. being probably a very burdensome form for the user, i'd like to give him the ultimate experience, and i really don't want to be restricted by programing difficulties here.
i thought that idealic every control should have an empty value at start except those of course, that have default values (the problem is DateTimePicker and such are not supporting empty value).
now the user can fill in any of the controls, in any order he would like. once he has leave the control, the program will validate the control's value, and any of the others validations which are concern with that control, and with other controls that are all non-empty (have been filed in already).
if there are any validation errors, the control is painted in some color, and in some side panel it will specify the errors (in a user friendly language of course, rather than exceptions' descriptions).
if there are errors that concerns to more than one control, only the last one that has been changed is painted.
i'd really like to keep to as many OOP concepts here..
so i have my logic classes, that are dealing with calculating the output and stuff like that. obviously those have nothing to do with the gui. now all of these complicated validations should be also in the logic classes' properties etc. but should be used in the gui as well, so i think there should be something like static validate methods (within the logic classes), that will be used in the gui, and in the logic classes them self.
the problem is, a logic class might contain up to 20 maybe 30 fields to validate... will that static method take 30 parameters? is that okay or is there more acceptable solution?
i'm a bit lost for anything beyond that.. but i'm quite sure there already are some conventions for these situations... i know it has something to do with design patterns, but i have no idea what design patterns there are, which are dealing with such cases, and where should i read about them.
my question basically is how do i integrate the validation of the logic classes and the gui, in the neatest way.
if i already in that, i don't want to open a new question for these:
as i mentioned, i need a method here, that get all the input, all the fields of the class, and somehow perform all the validation checks on the non-null values (if there is a validation check that concern to a few parameters, and even one of them is null, the validation shall not be execute). if you have any interesting ideas, i'd like to hear.
another problem i bump into, is the non-emptyale controls, such as DateTimePicker.... it's really ugly that it will have a certain value, while it should not... don't you think?
p.s.
sorry about my english.. i was too tired to write it perfectly..
EDIT1 working with windows
will that static method take 30
parameters?
Yes but what if you pass your object into your static validation method instead of all its properties individually ex.
public static class YourClassRules
{
public List<SomeSortOfValidationItem> Validate(YourClass obj)
{
var results = new List<SomeSortOfValidationItem>()
if (obj.YourProperty.Length >= 200)
{
results.Add(new SormSortOfValidationItem("YourProperty", "Length must be less than...");
}
//etc.
}
}
my question basically is how do i
integrate the validation of the logic
classes and the gui, in the neatest
way.
There are several different frameworks available. It would be helpful to know if your doing windows or web. Then we could make some recomendations.
another problem i bump into, is the
non-emptyale controls, such as
DateTimePicker.
Are you having issues with the controls or the properties that are bound to the controls. I often use DateTime? or Nullable which will allow for a null value.
Hope this helps.
DataAnnotations can be very easy to implement and very effective. Read this answer for an alternative that can extend further. Also, this question has some great gems regarding validation models too.
Spring has a very good DataBinding and validation API. Since there is a Spring.NET version, I'd recommend looking into it.
How can I set Resharper to wrap, say, the generated equality members with regions when selected from the Alt+Insert menu?
Thanks
there is usually a "wrap in regions" option towards the bottom of the dialog box, but not for this one. I would submit that to JetBrains as a request. For the time being, you'll have to select the generated methods and use the ctrl->E,U,5 (surroundwith shortcut) to get the expected result.
it doesn't really answer your question, but I just can't resist to try to convince you NOT to use regions. Why would you want to do it? The obvious disadvantages of regions are:
they don't compile, so you can never know if the name of the region really describes what is inside
regions are often used to hide rubbish code. The thinking here is: you can't see the rubbish bits, so it is as if they didn't exist. But guess what, they still exist...
regions are just textual, they don't have any semantic meaning. That means that the code inside the region can change the state of another region - which doesn't help to figure out what is happening in the class at all
if you structure your code correctly, it should be obvious what it is doing anyway
I believe using regions makes sense pretty much only for automatically generated parts, e.g. WinForms designer stuff. In most (all?) other cases it is much better to refactor the code, extract some extra classes or methods, etc. to make it clear.
You can highlight the text you are interested in wrapping and use the Visual Studio key shortcut of
CTRL + k, s
selecting #region from the menu.