C # Development Naming conventions

C # Development Naming conventions

1. Define Pascal capitalization: A case in which all words are capitalized in the first letter and lowercase in other letters. Camel capitalization: A case in which all words, except the first one, capitalize the first letter of the word,
He has a lowercase letter. Example: HelloWorld (Pascal capitalization), HelloWorld (Camel capitalization). Camel capitalization is primarily used for variable naming conventions, and other names are mostly used in Pascal capitalization, such as: Class name, file name, and so on. 2. Specification
The purpose of naming: see the name of righteousness. The ability to see the name of a person knows: type, meaning. Example: The interface name begins with "I" and represents interface. Indentation and spacing: Make the code beautiful and easy to understand. Good programming habits: keep the Rigor
Logic, the benefit of less detours. is also the idea of refactoring. A) class naming convention O name the class with a noun or noun phrase. Ø use Pascal capitalization. Ø reduce the amount of abbreviations used in the class name. Ø not
To use any class prefix. Ø do not use underlined characters. Here are some examples of correctly named class names. public class FileStream {} public class Button {} ps:c++ specification
Add "C" in front of the class name to change the name to the class name. b) Interface naming conventions o use nouns or noun phrases, or adjectives that describe behavior to name interfaces. For example, IComponent (descriptive noun),
ICustomAttributeProvider (noun phrase), and ipersistable (adjective). Ø use Pascal capitalization. Ø reduce the number of abbreviations used in the interface name. Ø do not use underlined characters. O
Prefix the interface name with I to indicate that the type is an interface. Ø do not precede the class name with the prefix c. Occasionally, you need to precede the class name with I and do not indicate that it is an interface. In this case, as long as the character after I is small
Write it (for example, Identitystore. Ø when a class is a standard execution of an interface, defining a pair of class/interface combinations will use a similar name. The difference between two names is just an I prefix in front of the interface name.
Let's take a look at the interface IComponent and its standard execution, class component, for example. Public interface IComponent {} public class Component:icomponent {} public interface
IServiceProvider {} public interface Iformatable {} PS: interface named similar naming specification, only prefixed with "I". c) method naming specification O use a verb or verb phrase to name the method.
Ø the method of naming the Pascal capitalization as shown in the example below. RemoveAll () Getchararray () Invoke () PS: The method is the operation, the verb is also! d) attribute naming specification o use noun or noun phrase to kill
Name property. Ø use Pascal capitalization to name the attribute. Ø attributes are the same as the type. PS: attribute is an element in C # that distinguishes it from other languages, and its combined accessors are equivalent to the Get,set method in JavaBean;
is also different from the field. e) variable naming specification o variables and method parameters use camel case public class HelloWorld {int totalcount = 0; void SayHello (string name) {
String fullmessage = "Hello" + Name; ...}} Ø do not use Hungarian methods to name variables. Previously, most programmers liked it-m_ the data type as a prefix to the variable name and as a prefix to the member variable. For example:
String M_sname; int nAge; However, in this way. NET coding specification is not recommended. All variables are written in camel case, rather than prefixed with data type and m_. Ø with a meaningful, descriptive
Words to name variables. -Don't use abbreviations. Use name, address, salary, etc. instead of NAM, addr, sal-Do not use single-letter variables like I, n, x, etc. use index, TEMP, etc.-variable exceptions for loop iterations: for
(int i = 0; i < count; i++) { ... } If a variable is used only as an iteration count and does not appear elsewhere in the loop, many people prefer to use a single-letter variable (i) instead of a different name. -Do not use underscores in variable names
(_) 。 -namespaces need to be named according to the standard mode. Ps:c++ has been using the Hungarian method to name the variable, C # has a new naming convention, followed! C # is also not used in the name "_". f) The file name should match the class name
For example, for class HelloWorld, the corresponding file name should be HelloWorld.cs (or, Helloworld.vb) PS: Same as Java. g) indent and interval o indent with TAB, without SPACES. Ø comments required and code
aligned. Ø the curly brackets ({}) need to be aligned with the code outside the brackets. Ø in a class, each method needs a blank line, and can only be a row apart. Ø the curly brackets need a separate line, not like if,
The for wait can be on the same line as the parentheses. Good: if (...) {//Do something} bad: if (...) {//Do something} Ø empty one grid before and after each operator. Good: If
(Showresult = = True) {for (int i = 0; i < i++) {//}} Bad: if (showresult==true) {for (int i= 0;i<10;i++) {//}}
Ps:.net in curly brackets {Independent line, then enter, more useful ^_^. Each operator is empty before and after the first space in the relationship/logical operator, and the ^_^ is corrected later. h) Good programming habits O
Avoid using large files. If the code in a file exceeds the 300~400 line, you must consider separating the code into different classes. Ø avoid writing too long methods. A typical method code is between 1~25 rows. If a method sends code that exceeds
25 lines, you should consider breaking it down into different methods. Ø the method name needs to be able to see what it does. Don't use names that will cause misunderstanding. If the name is at a glance, there is no need to use documentation to explain the functionality of the method (refactoring in a trick). Good:
void Savephonenumber (String phonenumber) {//Save the phone number.} bad://This method would Save the phone number. void SaveData (String phonenumber)
{//Save the phone number.} Ø a method only completes a task. Do not combine multiple tasks into one method, even if those tasks are very small. Good://Save the address. Saveaddress (Address
); Send an e-mail to the supervisor to inform, the address is updated. SendEmail (address, email); void Saveaddress (string address) {//Save the
Address. // ... } void SendEmail (string address, string email) {//Send an e-mail to inform the supervisor and the address is changed. / ... } Not good://
Save address and send an e-mail to the supervisor to inform the address is updated. Saveaddress (address, email); void Saveaddress (string address, string
email) {//Job 1.//Save the address.///Job 2.//Send an e-mail to inform the supervisor, the address is CH Anged. // ... } Ø use C # or vb.net
Rather than the alias type defined in the System namespace. Good: int age; String name; Object ContactInfo; Bad: Int16 age; String name; Object ContactInfo; Ø do not
Use fixed values in the program and replace them with constants.
Ø do not use the string constant, with the resource file (this should be noted, usually ignored). Ø avoid using many member variables. Declares a local variable and passes it to a method. Do not share member variables among methods. If in a few ways
Share a member variable, it is difficult to know which method changed its value at what time. o use enum when necessary, do not use numbers or strings to indicate discrete values (think of the benefits: easy to read, can be commented less ^_^). Good:
Enum Mailtype {Html, plaintext, Attachment} void SendMail (String message, Mailtype mailtype) {switch (mailtype) {CA SE mailtype.html://Do
something break; Case Mailtype.plaintext://does something break; Case Mailtype.attachment://does something break; Default
Do something break; }} bad: void SendMail (String message, string mailtype) {switch (mailtype) {case ' Html '://Do
something break; Case "plaintext"://Do something
Break Case "Attachment"://does something break; Default://do something break; }}ø do not declare member variables as public or
Protected The properties of the public/protected are generally declared private and used. Ø do not use the specific path and drive name in the code. Use a relative path and make the path programmable. O never Imagine
Your code is running on the "C:" Disk. You will not know that some users run the program on the network or "Z:" Disk. o make some "self test" when the application starts and make sure the required files and attachments are in the specified location. Check the database connection if necessary. Out
Now any questions to the user a friendly hint. Ø if the desired configuration file cannot be found, the application needs to be able to create a copy of the default value itself. Ø If an error value is found in the configuration file, the application will
Throws an error, giving the prompt message to tell the user the correct value. Ø the error message needs to be able to help the user solve the problem. Never use error messages such as "Application Error", "Discovery of an error", and so on. Instead, you should give the image "update database failed." Please ensure that the login
The land ID and password are correct. "The specific message. Ø when you display an error message, you should also prompt the user how to resolve the problem, in addition to saying something wrong. Do not use the like "Update database failed." "So, to prompt the user what to do:" Update the database
Failed. Please make sure the login ID and password are correct. Ø the messages displayed to the user are brief and friendly. However, all possible information should be recorded to help diagnose the problem. i) Note Ø each line of code, each declared
Variables are commented. Ø note in place of need. A readable code requires very little comment. If all variables and methods are well-named, it makes the code very readable and does not require much comment. Ø the number of lines is not much
Comments make the code look elegant. But if the code is not clear and the readability is poor, that's bad. Ø if a complex and difficult principle should be used for some reason, the program is equipped with good documentation and a re-divided annotation. j) Abnormal Place
Do not "catch the anomaly and do nothing". If you hide an exception, you will never know what happened to the exception. Ø When an exception occurs, give a friendly message to the user, but to accurately record the error all available
Details, including the time of occurrence, and related methods, class names, etc. Ø do not write too large try-catch modules. If necessary, write a separate Try-catch module for each task that is performed. This will help you find out which piece of code is producing an exception,
and send a specific error message to the user O if the application requires it, you can write your own exception class. Custom exceptions should not derive from the base class SystemException, but inherit from. Iapplicationexception. Good:
void ReadFromFile (String fileName)
{try {//read from file} catch (Fileioexception ex) {//Log error.//Re-throw exception depending in your case. thro W }} bad: void
ReadFromFile (String fileName) {try {//read from file.} catch (Exception ex) {//Catching general Exception are bad. .. We'll never know whether
IT//is a file error or some other error. Here is hiding an exception. In this case no one would ever know that a exception happened. Return
""; } }

SQL Server Naming conventions

Referring to the various naming conventions, we use the naming convention as follows: if there is an existing abbreviation in the naming process, use the abbreviation, if none, shall be abbreviated, for example: ISBN database: Use one or three of the following English words
The first letter of the word is capitalized, such as: departmentmanage; table name: Use noun-like words full spelling, each word capitalized, using a plural form, such as: Books if the table is used to indicate the closing between the fields in the other two tables
System, with the singular (that is, the table that indicates the relationship between entities is named with the singular), there is no preposition in the middle of the word "and of in" such as: Bookauthor 1. The fields in the table are generally spelled with a noun-character word, using one or three of the following English words
The first letter of the word is capitalized, such as: UserName; 2. The table primary key name is: Table name +id, such as the primary key name of the document table is: DocumentID 3. Foreign key Name bit: Main Table name + corresponding column name, such as: Departmentsid, described as follows:
In table departments, its fields are: ID, departmentname in table UserInfo, its fields are: Userid,username,departmentsid departmentsid is foreign key 4. The automatically-growing columns in the table are named:
ID; 5. If the field is of type bool, use "Isshow", "IsValid", "haspassed", "hasexamined", "IgnoreCase" in this form; 6. If the field is DateTime, the tangent and default value is the system time, which is named
For: addtime; preferably by program control. 7. Status is the column name of the state in the table, the default value is 0, the delete operation in the table will change the value of status and not the actual deletion of the record; if it is deleted, it is delstatus ... 8. Stored Procedure Life
Name: Sp_ Table Name _ method, such as: sp_news_add,sp_news_update; 9. View Name: Vi_ table name, such as: vi_news; 10. All objects such as tables, stored procedures, views, and so on are dbo, and do not use the database user name, which affects the number
Changes to the repository user

C # Development Naming conventions