Objective
Very many programming specifications are in contact with the work. The most interesting thing is that the company recently released a version of the C/s programming code, and then I see the last paragraph of the specification, there is a sentence: "This specification does not apply to Windows platform development." It seems that this specification was developed by students doing other platform development. So where are all the people who did windows development go? Later, because of the need for work, the project team needed me to develop a programming specification. This is the origin of my blog series. (reprint please indicate CSDN blog for breaksoftware)
When it comes to "specs", maybe not many people like this kind of thing. I believe a lot of project architects, like me, love some of the qualities of the Internet: freedom and inclusion. Do unto others come back haunting, so I set the "norm", but also with an open attitude-after the "specification" added the word "recommendations". Thereafter, I will collectively refer to these ordinances as "recommendations".
If the designation "spec" is easy (in fact, it is not), then the hardest thing to do is to let people obey. The general assumption is that we want to follow what we are, and we must first think about why we should obey, what advantages we follow and what we can bring to us. The same I also follow this thinking to make this "advice", I will from the code of readability, maintainability, robustness, and other perspectives, thinking and compiling the "recommendations." Hopefully these "suggestions" will help you write code that is more readable, robust, and better-looking.
This "recommendations" ordinance is divided into the following levels:
" must be " |
encoding must be followed. |
/p> |
This rule can improve legibility, efficiency and security. In exceptional circumstances, it is not possible to comply, but a reason for non-compliance is required. |
"recommended" /p> |
This rule can partially improve legibility, efficiency, and security. In most cases, compliance is required. |
"recommended" /p> |
The rule is just as a recommendation, and the code author is able to decide on its own inference. |
The sample code in this recommendation uses a different undertone to indicate whether the code has problems:
Indicates that there is a problem with the code.
Represents a way to fix a problem code.
This recommendation will be divided into several modules below. I will update these regulations on a regular basis, based on new discoveries and understandings from my work and suggestions from my friends. And the update history is at the end of the article for everyone to check.
Module:
- functions windowsclientc/c++ Programming Specification Recommendations "--functions"
- pointers windowsclientc/c++ Programming Specification Recommendations "--pointers"  
- function calls windowsclientc/c++ Programming Specification Recommendations "--function calls"
- expressions and Operations windowsclientc/c++ Programming specification recommendations-expressions and operations
- structure windowsclientc/c++ Programming Specification "-structure"
windowsclientc/c++ Programming Specification "recommendations"-- Macro
- file windowsclientc/c++ Programming Specification "Recommendations"--file
- variables and constants windowsclientc/c++ Programming Specification Recommendations "-Variables and constants"
- style & nbsp windowsclientc/c++ Programming specification recommendations-style
Update history:
Time |
Content |
Note |
2014.07.18 |
Input "Recommendations" |
Draft |
Windowsclientc/c++ Programming Specification "Recommendations"--preface