A successful development team requires each member of the team to adhere to code reuse rules that push the reusability of the code to the extreme without significantly reducing the developer's creativity and development efficiency. If the developer who writes and uses code adheres to common program naming conventions and code comment requirements, then the reusability of the code will be greatly improved. The starting point for these standards is the system architecture level. Your functional specifications should reflect these criteria in the definition of the class, the name of the property, the function return value, and other key program elements. This article will present some practical suggestions on basic naming rules and annotations, intended to help readers develop their own code reuse standards.
Case-sensitive Standard
Before we begin to discuss the proper ways to name all kinds of program elements, let's first define the two most common ways to differentiate between the character case of an element:
Pascal specification-The 1th character is capitalized, and the 1th letter of each word in the target name is also capitalized, such as InvoiceNumber or Printinvoice. All other characters are lowercase.
Camel specification-The 1th character is not very written, but the 1th letter of each word in the target name is capitalized, for example, InvoiceNumber. All other characters are lowercase.
However, using character-case-sensitive elements may cause problems in programming languages that are not case sensitive. For example, because the C # language is case-sensitive, you can call the private variable employee, and then the public property employee it has can be used by the caller. These operations are completely legal. However, for Visual Basic, there will be errors, because VB is not sensitive to the case of letters, the above two elements in VB seems to be one thing. If you are working in a mixed language environment, you can only specify certain rules that require developers to reasonably use multiple languages to read code developed by others.
Naming standards
Assuming we've adopted the above case criteria, let's now look at some simple naming suggestions for common program elements.
Class
Some classes are designed to mimic real-world objects, and for these classes, the names you choose should reflect real-world objects and formats with singular nouns, such as employee, invoice, or timecard. For internal classes, the Pascal specification can be used to make the resulting class have a singular name, such as ThreadPool or Customcolor. Classes should be singular, so that their plural forms can represent similar sets of names, such as employees arrays.
Members of the class
Developers who use C # and other case-sensitive programming languages should use the name of the camel canonical named Class member. Doing so makes it easier for developers to distinguish between the name of the internal variable and the name of the public property (name). Many VB developers prefer to use the Hungarian nomenclature for class members, that is, prefixed with a prefix to indicate the type of the variable, such as sname refers to the string type of the name variable. I think it's unnecessary to do this in a high-level development environment using vs.net, because in this case the system mouse hovers over the variable to automatically display the type of the variable. I personally like to prefix the class member name with the lowercase letter m. This internal variable preserves enough internal class information: The internal variable mname just represents the public property name.
Method
Methods should be named after the Pascal specification, and in a reasonable manner to explain their implementation behavior. For example, the method of adding an employee to a database can be named AddEmployee, and the method of printing the invoice may be named Printinvoice. If the method returns a Boolean value, the method name should begin with a verb so that it is more pronounced when used in the IF statement. For example, if you have a method that determines whether an employee meets the requirements of the company's 401k plan, you can call the iseligible401k method in the IF statement: if iseligible401k then ...
Method parameters, return values, and variables
All method parameters, return values, and variables should be named with the Pascal specification, which should reflect the meaning of the parameter or variable as well as the method name. This is especially important for parametric methods because IntelliSense returns parameter names and argument types when you invoke a method. All developers adopting a method should use descriptive names and types to understand each other's meaning.
Control
Naming a control is a frequently controversial issue in the development world. While most people agree that the default names of controls should not be used, such as TextBox1 or LABEL1, they are also opposed to naming controls in the same way as variables or using prefixes to represent the type of control. I prefer to name the controls in the form using the standard three-letter prefix. For example, a TextBox control that holds the last name and first name may be named Txtlastname and txtFirstName, respectively. command buttons that process form data can be named Cmdsubmit or Cmdcancel. In fact, as long as you can guarantee the consistency of the control naming and the standard is easy to understand.
Comments
The comment code is necessary for all developers. In order to teach the correct annotation technique, I often add comment code in my own demo program. Also, to simplify the annotation process, I recommend that developers first write comments explaining the programs they want to write. I will first write the procedure, class, or other program elements in the program, but do not elaborate on its specific workings. Then I'll write a series of comment codes that describe each of the main steps of the process or the elements of the class. After writing the code that defines the class or describes the procedure, I document the various external variables, controls, open files, and even the elements accessed by other procedures, and briefly describe the input parameters and return values.
If you are using C # development, the VS.NET environment already has built-in tools to help you convert internal C # annotations to external HTML documents. You can change the way external documents are represented by adding special processing indicators to your documents. For more information on this, refer to the vs.net internal Help file: Ms-help://ms. Vscc/ms. Msdnvs/csref/html/vcorixmldocumentation.htm.
http://www.bkjia.com/PHPjc/318493.html www.bkjia.com true http://www.bkjia.com/PHPjc/318493.html techarticle A successful development team requires each member of the team to adhere to code reuse rules that push the reusability of code to the extreme without significantly reducing the developer's creativity and open ...
