Successful development teams require every member of the team to abide by code reuse rules. These rules push the reusability of code to the extreme without significantly reducing the creativity and development efficiency of developers. Code reusability is greatly enhanced if developers who write and use the code adhere to common program naming conventions and code comment requirements. The starting point for these standards is at the system architecture level. Your functional specification should reflect these standards in the definitions of classes, property names, function return values, and other key program elements. This article will provide some practical suggestions on basic naming rules and comments, with the intention of helping readers develop their own code reuse standards.
Case Standards
Before we start discussing the correct way to name various program elements, let us first define the two most commonly used case-sensitive characters for elements. Methods, they are:
Pascal specification - the first character is capitalized, and the first letter of each word in the target name is also capitalized, such as InvoiceNumber or PrintInvoice. All other characters are lowercase.
Camel specification—the first character is not capitalized, but the first letter of each word in the target name is capitalized, for example, invoiceNumber. All other characters are lowercase.
However, using character case to distinguish elements may cause problems in case-insensitive programming languages. For example, since the C# language is case-sensitive, you can call the private variable employee, and then its public property Employee can be used by the caller. These operations are completely legal. However, an error will occur for Visual Basic, because VB is not case-sensitive, and the above two elements are the same thing in VB's eyes. If you work 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 adopt the above case standards, let us now look at some simple naming suggestions for common program elements.
Classes
Some classes are designed to simulate real-world objects. For these classes, the names chosen should reflect the real-world objects, with singular nouns, such as Employee, Invoice, or Timecard etc. For inner classes, the Pascal specification can be used to make the result class have a singular name, such as ThreadPool or CustomColor, etc. Classes should be singular so that their plural form can represent collection names of the same type, such as the Employees array, etc.
Members of a class
Developers using C# and other case-sensitive programming languages should use the camel convention for naming class members. Doing so makes it easier for developers to distinguish between the names of internal variables and the names of public properties. Many VB developers prefer to use Hungarian nomenclature to name class members, that is, adding a prefix in front of the name to indicate the type of the variable. For example, sName refers to the Name variable of string type. I think it is unnecessary to do this in an advanced development environment such as VS.NET, because in this case the system's type of variable can be automatically displayed by hovering the mouse over the variable. I personally like to prefix class member names with the lowercase letter m. In this way, the internal variable saves enough internal class information: the internal variable mName just represents the public attribute Name.
Methods
Methods should be named according to the Pascal specification and describe their implementation behavior in a reasonable way. For example, the method for adding employees to the database can be named AddEmployee, and the method for printing invoices can be named PrintInvoice. If the method returns a Boolean value, the method name should start with a verb so that its meaning is more obvious when used in an 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 an If statement: If IsEligible401k then...
Method parameters, return value, and Variables
All method parameters, return values and variables should be named according to Pascal specifications. Like method names, they should also reflect the meaning of the parameters or variables. This is especially important for parameter methods, because Intellisense returns the parameter name and parameter type when you call the method. All developers using methods should use descriptive names and types so that their meaning is mutually understood.
Control
Control naming is an often controversial issue in the development field. Although most people agree that the default names of controls should not be used, such as TextBox1 or Label1, etc., they also object to naming controls as variables or using prefixes to indicate the type of control. I prefer to use the standard three-letter prefix for naming controls on a form. For example, the text box controls that store the first and last names may be named txtLastName and txtFirstName respectively. The command button that processes form data can be named cmdSubmit or cmdCancel. In fact, as long as you can ensure that the control naming is consistent and the standard is easy to understand.
Comments
Commenting code is necessary for all developers.In order to teach proper annotation techniques, I often add annotated code to my demo programs. Also, to simplify the annotation process, I recommend that developers first write comments describing the program they want to write. I will first write comments to describe the procedures, classes, or other program elements in the program, but not explain how they work. Then I would write a series of commented code describing each major step of the process or element of the class. After writing the code that defines the class or describes the process, I document each external variable, control, open file, and even elements accessed by other processes, and briefly explain the input parameters and return values.
If you are using C# to develop a program, the VS.NET environment already has built-in tools to help you convert internal C# comments into external HTML documents. You can add special processing directives to your own document to change the way the external document is represented. For more information about this, please refer to the VS.NET internal help file: ms-help://MS.VSCC/MS.MSDNVS/csref/html/vcoriXMLDocumentation.htm.