Software Project Quality Assurance-coding specifications

Directory

I. Functions of coding specifications

The second encoding specification is not "God of things"

3. Suggestions for coding specifications

Four encoding specifications reference

As software developers, we can develop low-level software, but not low-quality software. Therefore, how to implement quality assurance is one of our main concerns, while coding specifications are the first step in implementing quality assurance.

Coding standards have become a common issue. Almost every company defines its own coding standards for every project. However, in actual implementation, the code specification is violated intentionally or unintentionally.ProgramMembers, do not like to change their programming habits. In addition, due to the lack of quality control by managers, coding standards are often ineffective. Some people will think that compliance with coding standards cannot bring benefits to the project, nor allow customers to see our efforts. It is a spontaneous behavior of the team and there is no need to make a hard requirement. Some people have a better reason: Coding norms will undermine creativity and program quality. I believe that coding standards play an important role in software components, project management, and even personal growth. Good coding standards are to improve ourCodeOne of the most effective tools for quality.

I. Functions of coding specifications

• Improve readability"Any fool can write code that can be understood by computers. Only code that is easily understood by humans is a top programmer ." Coding standards help us write code that is easy to understand. It provides us with the most basic templates and a good coding style, so that the code can be descriptive, you can get some prompts that require IDE, such as accessibility and Inheritance of base classes.
• Unify the global environment and promote team collaborationDeveloping software is a team activity, not a personal heroism. Coding standards require team members to follow this unified global decision, so that Members can easily read the code of the other party, and all Members are coding in a clear and consistent style. In addition, developers can focus on the issues they really need to pay attention to-the business logic of their own code, the fit of their needs, and other local issues.
• It facilitates knowledge transfer and accelerates work HandoverStyle similarity makes it easier for developers to understand unfamiliar code and others' code more quickly. Because he and your code have the same style, you do not have to speculate on some of his personalized styles. The advantage is that developers can quickly take over the work of other members of the project team and quickly complete the work handover.
• Reduces name proliferation and maintenance costsIn the absence of a specification, the name is different from the name of an instance of the same type. There will be doubts for programmers who will maintain these codes in the future.
• Emphasize the relationship between variables to reduce the opportunity for defects to become attractiveNaming can represent a certain logical relationship. It is an opportunity for developers to be vigilant when using the name, so as to reduce defects to a certain extent.
• Improve the individual abilities of programmersIt is undeniable that every programmer should develop a good coding habit, which is undoubtedly one of the teaching materials. A programmer's code can tell a lot. Therefore, even for their own development, as a programmer, there is no reason to resist the existence of such rules. You may not realize that we are quietly benefiting from coding standards.

The second encoding specification is not "God of things"

In high-quality software, you can see the relationship between "conceptual integrity of architecture" and "underlying implementation. The "Implementation" and "architecture" must be clear and consistent. This internal and inherent consistency needs to be maintained by coding specifications. Without such a unified convention, what we make may be filled with different styles, which seem confusing and hard to understand. Team members may not understand each other's ideas or even attack each other. The differences in various coding styles will continue to expand, while the code quality will continue to decline. In addition, team members spend time understanding the differences between different programming styles, rather than focusing on the issues that really should be addressed. Such time consumption is unacceptable. Therefore, there must be an excellent coding standard behind every high-quality code.

However, we must also realize that the encoding specification is not "God of things ". The encoding specification is only a global specification. It is just a programming Convention and cannot solve deeper problems. Just as a beautiful paper with poor content cannot be published, you can't just rely on one specification to get rid of software workshops. In addition, coding specifications should not contain lengthy development skills. In my opinion, the best practice for code should be solved by code review, and we should avoid writing code standards into a textbook on refactoring.

3. Suggestions for coding specifications

The following are my suggestions for defining coding specifications:

• Similarities and DifferencesDo not try to change the organization's coding habits. Unless there is absolutely a reasonable reason, it is still dominated by democracy. After all, you have no right to require everyone to follow your coding habits.
• The sooner the encoding specification is defined, the better.We also use encoding standards early and enjoy the benefits they bring.
• Divide the specification into mandatory and recommendation partsThe specific implementation of the same premise. Place the most basic specification columns in the mandatory section, which must be followed by all members. place good but unimportant habits in the recommendation section. developers can choose whether to use them based on their habits.
• The encoding specification should not be too long.No one looks at documents that are too long. Everyone is the same. No one is willing to look at long things except the gift list and payroll. Therefore, the coding specifications must be refined, preferably only 2 ~ Three pages, allowing developers to print them out and view them at any time.
• Must be conventionalStandards must be customary in the industry and should not be personalized.

Four encoding specifications reference

I personally do not recommend that you develop detailed coding specifications. Coding standards are formulated to enhance the readability of the Code. After all, the structure of the Code is the main concern, so my coding standards are relatively short. It only imposes restrictions on behaviors that may damage the encoding style, but does not go down to the "empty line" or even "space" level.

Code Specification

1. namespace

<Company Name>. (<Product Name> | <related technology>) [. <purpose>] [. <sub-namespace>]

Code style

• The curly braces "{}" cannot be omitted, even if there is only one piece of code.
• The access modifier cannot be omitted.
• The default type is sealed.
• Fields cannot be published.
• Use parentheses () to emphasize the operator priority.

Iii. Naming rules

(1) Naming of classes, structures, and interfaces

• Use a noun or noun phrase.
• Use Pascal.
• Add the prefix "I" before the interface name ".
• Consider using the base class name at the end of the derived class.
• If this class only implements an interface, keep it consistent with the interface name.
• If a type is derived from an existing type in the. NET Framework, the following specifications should be observed:

Base Class	Derived class
System. Attribute	Add the suffix "attribute" to the custom feature
System. Delegate	Add the suffix "eventhandler" to the delegate used for event processing. Add the "Callback" suffix to the delegate used for event processing. Do not add the suffix "delegate" to the Delegate
System. eventargs	Add the suffix "eventargs"
System. Exception	Add the suffix "exception"
Idictionary, idictionary <t, V>	To add a "Dictionary" suffix
Ienumerable, icollection, ilist, Ienumerable <t>, icollection <t>, ilist <t>	Add "Collection" suffix
System. Io. Stream	Add "stream" suffix
Codeaccesspermission, ipermission	Add "permission" suffix

(2) member naming

Member	Case sensitivity	Specifications
Method	Pascal (public), camel (private)	Name By verb or verb phrase
Attribute	Pascal	Use nouns, noun phrases, or adjectives for naming. The set attribute should be in the plural form, instead of adding a suffix. Use "is", "can", and "has" to represent Boolean attributes. You can use the type name of the attribute to name the attribute.
Event	Pascal	Use a verb or verb phrase to name an event Use the current time and past time to distinguish between pre-and post-Events
Field	Camel (private)	It must be named by a noun, noun phrase, or adjective. Do not add any prefix

(3) parameter naming

• Camel style.
• You need to use left and right to name the parameters of the overloaded binary operators -- if the parameters have no specific meaning.
• You need to use value to name the parameter of the overloaded unary operator -- if the parameter has no specific meaning.
• Do not use numeric numbers in parameters.
• Use descriptive names to name generic parameters and use the "T" prefix.

(4) Naming of constants and variables

• Constant -- all words are capitalized and separated.
• Local variable --Camel style.

(5) Enumeration naming

• Pascal style.
• Use the plural form of a noun to name tag enumeration.
• Do not add the suffix "Enum" or "flag.
• Do not add a prefix to the name of an enumerated value.

(6) Resource naming

• Pascal style.
• Only letters, numbers, and underscores are used.
• When naming an exception message resource, the resource identifier should be an exception type name with a short exception identifier.

(7) database naming

• Table -- "module name_table name ".
• Field-the bool type is represented by "is", "can", and "has". The date type name must contain "date", and the time type must contain "time ".
• Stored Procedure-use the prefix "proc.
• View -- use the prefix "VIEW.
• Trigger -- use the prefix "trig.

(8) XML Naming

The node name uses the Pascal style, and the attribute name uses the camel style.

4. Notes

• Comments must be made to interfaces and complex code blocks.
• Keep comments synchronized when modifying code.
• Incomplete features are marked with todo.
• When modifying others' code, you must first comment on the code of the other party and specify the reason for the modification. You cannot delete others' code at will.
• Remove unnecessary comments before release.

5. Exception Handling

• In principle, only four exception types can be displayed: invalidoperationexception, argumentexception, argumentnullexception, and argumentoutofrangeexception.
  
• When creating a custom exception, you must use the code template provided by Vs to create a custom exception.