1.1 naming rules 1.1.1 database element naming rules all Use lowercase letters.
| Type |
Prefix |
Example |
Description |
| Form |
T |
T_bi_city |
|
| View |
V |
V_bi_city |
|
| Stored Procedure |
P |
P_bi_city_insert |
|
| Trigger |
TG |
Tg_bi_city |
|
1.1.2 naming rules for common controls
| Type |
Prefix |
Example |
Description |
| Textbox |
Txt |
Tbx_custno |
|
| Checkbox |
Chk |
Cbx_yn |
|
| Button |
BTN |
Btn_ OK |
|
| ComboBox |
CMB |
Cbx_department |
|
| ListBox |
LST |
Lbx_students |
|
| Imagebutton |
IBT |
Ibt_confirm |
|
| DataGrid |
DGD |
Dgd_dataquery |
|
1.1.3 functional naming rules are meaningful English word combinations. Each word is capitalized. For example, hasoprright () (indicates whether the user has the permission to perform an operation) 1.1.4 The constant naming rule uses uppercase letters. 1.1.5 The variable naming Rules use the following naming rules to facilitate code reading and incorrect search:
| Type |
Prefix |
Example |
Description |
| Int |
I |
I _totalcount |
|
| String |
S |
S_username |
|
| Bool |
B |
B _hasoperatergt |
|
| Date |
D |
D_nowdate |
|
1.2 encoding rules 1.2.1 SQL statement rules in code 1 keywords in SQL statements are in lowercase; 2 tables and fields in SQL statements are in uppercase; 3 SQL statements, if they are generic queries, store SQL statements as constants in the constant table of common functions. Otherwise, the position defined by the constant variable of the Class header must be stored. For example, private const string updaterolesql = "Update t_usr_role_ass set data_right = '{2}' Where usr_id = {0} And role_id = {1 }"; 1.2.2 session variable rule 1 the keywords of all sessions must be defined in the constant table of the public module; 2 the session description should be provided when the session is defined; for example: // session ["multipagelistcont"] ----> stores multi-page objects. 3. The session must specify the transfer range of the session, such as on that page or in those modules, or in all range, and you must specify where to clear the session. Write the session clearing statement to the public function for checking. 1.2.3 comment Rule 1 in the desired place, do not line the Code, every declared variable is annotated. 2. initialize a numeric variable with a value other than 0 or-1 to give the reason for selecting the value. 3. Check the spelling of the comment to ensure the correct use of the syntax and punctuation. 1.2.4 class rule 1 the code of a class cannot exceed 400 lines. If the code of a class exceeds 300 ~ Line 3: Separate the code into different classes. 2. Different methods in a class must be separated by blank rows. 1.2.5 function rule 1 the code of a function cannot exceed 25 rows. A typical method code is in the range of 1 ~ Between 25 rows. If a method code contains more than 25 lines, you should consider breaking it into different methods. 2. A function can only complete one task. Even if the task is very small, do not combine multiple tasks into a function. 3. You must be able to see the function of the function from the function name. Do not use a wrong name. If the name is clear at a glance, you do not need to use the document to explain the functions of the method; 4 the curly arc needs to have an independent line, not like if, for, etc., which can be the same line as the brackets; 5. Fill in a space before and after each operator and bracket. 6. Use C # Or VB.. net, rather than the alias type defined in the system namespace. For example, the solution is int age; string name; object contactinfo; the method is int16 age; string name; object contactinfo; 7. Do not use a fixed value in the program, replace with constants. Resource source file; 9 avoid using many member variables. Declare local variables and pass them to methods. Do not share member variables between methods. If a member variable is shared among several methods, it is difficult to know which method modifies its value. 10 if necessary, use enum, do not use numbers or strings to indicate discrete values. For example, the best practice is: Enum mailtype {HTML, laintext, ttachment} void Sendmail (string message, mailtype) {Switch (mailtype) {Case mailtype. HTML: // do something break; Case mailtype. plaintext: // do something break; Case mailtype. attachment: // do something break; default: // do something break;} the incorrect method is: void Sendmail (string message, string mailtype) {Switch (mailtype) {Case "html": // do so Mething break; Case "plaintext": // do something break; Case "attachment": // do something break; default: // do something break ;}} 11 do not declare the member variables as public or protected. Both are declared as private, with the properties. 12 of public/protected not in the code using the specific path and drive name. Use relative paths and make the paths programmable. Never imagine that your code is running on the "C:" disk. You don't know, some users run programs on the network or "Z:" disk. 13. Perform "self-check" when the application starts and ensure that the required files and attachments are in the specified position. Check the database connection if necessary. If any problem occurs, give the user a friendly prompt. 14 if the required configuration file cannot be found, the application must be able to create a copy using the default value. 15 if an error value is found in the configuration file, the application will throw an error and a message will be prompted to tell the user the correct value. 16. The error message must help you solve the problem. Never use error messages such as "application error" or "discover an error. It should be similar to "updating the database failed. Make sure that the logon ID and password are correct .". When an error message is displayed, in addition to the error message, you should be prompted about how to solve the problem. Do not use something similar to "failed to update database ." In this case, you should be prompted how to do this, for example, "updating the database failed. Make sure that the logon ID and password are correct ." 17 The message displayed to the user must be short and friendly. However, all possible information should be recorded to help diagnose the problem. 1.2.6 Exception Handling 1. Do not "catch exceptions but do nothing". If an exception is hidden, you will never know whether the exception has occurred. 2. When an exception occurs, a friendly message is provided to the user, precisely recording all possible details of the error, including the occurrence time, related methods, and class names. 3. capture specific exceptions instead of general exceptions. For example, the good practice is: void readfromfile (string filename) {try {// read from file .} catch (fileioexception ex) {// log error. // re-throw exception depending on your case. throw;} bad practice: void readfromfile (string filename) {try {// read from file .} catch (exception ex) {// catching general exception is bad... we will never know whether it // was a file error or some other error. // here you are h IDing an exception. // In this case no one will ever know that an exception happened. return "" ;}} 4 do not catch general exceptions in all methods during the development cycle. Directly let the program throw an exception, which will be able to find the majority of errors during the development cycle; 5. You can use the application-level (thread-level) Error processor to handle all general exceptions. In the event of a "non-General error", the error processor should capture the exception and send a message to the user to record the error message before the application is closed or the user selects "ignore and continue; 6. Try-catch is not required for each method. It is used only when a specific exception may occur. For example, when writing a file, you can handle the exception fileioexception; 7. the try-catch module cannot contain too much content. If necessary, write a separate try-catch module for each executed task. 8. If the application needs to, you can write your own exception classes. Custom exceptions should not be derived from the base class systemexception, but must inherit from iapplicationexception.
