.NET naming convention for class and form definition

I have a lot of developed in Windows.NET forms, and each of them is named because they have no prefixes. However, I often have to declare another class containing the column names that the form uses.

For example, I have an Address class, which is a form for serving addresses. However, I also need a class that I would also like to call an Address, which basically just contains the declarations of the Name and Address fields. I am looking for a good naming convention to distinguish between the two (class definition in relation to form).

+4
source share
5 answers

The normal convention for Windows Forms is to suffix the form class names with Form . Thus, your class for the address should simply be called Address (because, after all, this is the address), but the form used to edit the addresses should be AddressForm (or AddressListForm or AddressEditorForm , etc. - depends on what exactly he does).

+11
source

Maybe this?

 class Address { } class AddressForm { } 
+8
source

Use Namespaces .

So your form can be in the namespace

 YourCompanyName.UI.WinForms.Address 

Your value object may be

 YourCompanyName.Business.Values.Address 

Then you can simply use the full namespace to refer to them.

+3
source

I suggest Address and AddressForm (or AddressEditor or something like that). The naming of the Address form seems wrong to me - the class does not represent an address, but a form for viewing or manipulating addresses.

+1
source

If the forms are for a modal form, you can use Dialog instead of Form as a suffix.

In addition, I will use the keyword "Editor", "Properties" or "Browser" to indicate the purpose of the forms.

AddressEditorForm, AddressPropertiesForm is better than AddressForm.

0
source

All Articles