1 Name Rules and Style Naming Conventions and Style
2 Coding conventions Coding practices
3 Project Settings and Structure Project Settings and Structure
4 Framework Special Guidance Framework Specific Guidelines
4.1 Data Access Data Access
4.2 ASP.NET and Web Service ASP.NET and Web Services
4.3 Serialization Serialization
4.4 Multi-Thread Multithreading
4.5 Remoting Remoting
4.6 Safety Security SECURITY
4.7 Service Components Enterprise Services
5 Resources Resources
Today, I only translated the naming rules, the translation and the original parties are as follows, and the TIP is attached, :-)
Naming rules and style Naming Conventions and Style
1. The use of class and method names pascal style use pascal casing for type and method names public class someclass {public somemethod () {}} 2. parameters using local variables and methods from camel use camel casing for local variable names and method arguments int number ; void mymethod (int somenumber) {} 3. i interface name as a prefix using prefix interface name with i interface imyinterface {..} 4. private member variables employed m_ prefix prefix private member variables with m_ public class someclass {private int m_number;} 5. Custom attribute class name uses Attribute as the suffix suffix custom attribute class with attribute. 6. Customized exception class name uses Exception as the suffix Suffix Custom Exception Classes with Exception. 7. Using the verb-object to naming methods, for example showdialog () name methods using verb-object pair, such as showdialog () 8. the method should return a value of the return value name represents, for example getobjectstate () methods with return values should have a name describing the value returned, such as GetObjectState (). 9. Adopt a descriptive variable name. Use descriptive variable names. a) Avoid using single-letter variable names, such as i or t; but use index or temp. Avoid Single Character Variable Names, Such As I OR T. Use index or temp instead. b) Avoid using Hungarian nomenclature for public and protected members. Avoid Using Hungarian NOTATION for PUBLICOR PROTECTED MEMBERS. C) Do not use abbreviations (for example, Number abbreviations as num). Do Not Abbreviate Words (SUCH AS NUM INSTEAD OF Number). 10. Always use the C # predefined type instead of using the alias in the System namespace. For example, using Object does not have to use Object, use String without String, using int32 without INT32. Always Use C # predefined Types Rather Than The Aliases in The System Namespace. for example: Object Not Ibject String Not String Int Not Int32 11. For generics, the type is capitalized. Retain the suffix type when processing .NET type Type. WITH GENERICS, USE CAPITAL Letters for Types. RESERVE Suffixing Type. // Correct: // Correct: Public Class LinkedList // Avoid: // Avoid: Public Class LINKEDLIST 12. It is meaningful Name space name, such as product name or company name.
Use meaningful name or the company name. 13. Avoid using the full name of the class, but use the USING statement. Avoid Fully Qualified Type Names. Uses Using Statement INSTEAD. 14. Avoid using the USING statement in the namespace. Avoid Putting A Using Statement Inside A Namespace. 15. Place all Framework namespace names together, place the namespace name defined or third parties. group all framework namespaces together and put custom or third party namespaces underneath using system;. using system.collections; using system.componentmodel; using system.data; using mycompany; using mycontrols; 16. Principal uses inference, not explicitly delegate instantiation . Use delegate inference instead of explicit delegate instantiation delegate voidate (); public voids () {} somedelegate somedelegate = someMethod; 17. Strictly observe the indentation format. MAINTAIN STRICT INDENTATION. A) Ind retains 3 spaces. Use 3 spaces for indentation. b) Do not use Tab or non-standard indentation, such as 1, 2 or 4 spaces. Do Not Use Tabs or Non-Standard Indentation Like 1, 2 Or 4 Spaces. 18. Note The code that retransmate and its comment is on the same level. Indentation at the same level of indeentation as the code you aredoming. 19. All comments should be spell check. The annotated note indicates the development of the grassroots. All Comments Should Pass Spell Checking. Misspelled Comments INDICATE SLOPPY Development. 20. All member variables should be defined in front, and attributes or methods are vacant. All Member Variables Should Be Declared At The Top, With Line Separating Them from The Properties Or Methods. Public Class Myclass {INT M_NUMBER; String M_Name
Public void someMethod1 () {} public void someMethod2 () {}} 21. The definition of local variables is as close as possible to its initial use. Declare a local variable as close as possible to it it .. 22. The file name should reflect the class it contains. A File Name SHOULD REFLECT The Class It Contains. 23. When using the Partial type and assigns a file per part, naming each file with a type name P and order. when using partial types and allocating a part per file, name each file after the type suffixed with ap and an ordinal number: // in myclassp1.cs public partial class myclass {} // in myclassp2.cs public partial class myclass {} 24 Left braces are always placed in the new row. ALWAYS Place An Open Curly Brace ({) in a new line. 25. Anonymous method mimics the layout of ordinary methods, and anonymous delegate definitions are placed in one line. WITH Anonymous Methods Mimic The Code Layout of a Regular Method, Aligned with The Anonymous Delegate Declaration. A) Compliance with the rules of the left bracers in the new row. comply with placing an open curly brace in a new line delegate void somedelegate (string somestring); // correct // correct: public void invokemethod () {somedelegate somedelegate = delegate (string name) {messagebox.show (name);}; Somedlegate ("juval");} // avoid use: // Avoid Public Void InvokeMethod () {somedlegate somedlegate = delegate (String name) {messagebox.show (name);}; somedlegate ("juval");} 26. Anonymous methods without parameters use empty brackets. Use Empty Preenthesis On Parameter-Less Anonymous Methodsa) Only when an anonymous method may be used for any delegation, the brackets are omitted. omit the parenthesis only if the anonymous method could have been used on any delegate delegate void somedelegate ();. // correct somedelegate somedelegate1 = delegate () {messagebox.show ( "hello");}; // avoid somedelegate somedelegate1 = delegate {MessageBox.show ("Hello");}; 2 Coding Form Coding Practices
1. Avoid multiple classes in one file. Avoid Putting Multiple Classes in a Single File. 2. A file should only provide types of namespaces. Avoid having multiple namespaces in the same file. A Single File Should Only Namespace. Avoid Having Multiple Namespaces in The Same File. 3. Avoid the file length of more than 500 rows (except for the code automatically generated). Avoid Files With More Than 500 Lines (Excluding Machine-Generated Code). 4. Avoiding the method to define more than 25 lines. Avoid Methods with More Than 25 Lines. 5. Avoid more than 5 parameters. Use structures to pass multiple parameters. Avoid Methods with More Than 5 Arguments. Use Structures for Passing Multiple Arguments. 6. Each line should not exceed 80 characters. Lines Should Not Exceed 80 Characters. 7. Do not edit any machine generated by any machine. DO NOT MANUALLY Edit Any Machine Generated Code. a) Modify the code generated by the machine to modify the code format and style to meet this coding standard. If MODIFY AND STYLE TO MATCH THIS Coding Standard. b) use the Partial class as much as possible to decompose some parts that require maintenance. Use Partial Classes WHENEVER POSIBLE TO FACTOR OUT The Maintained Portions. 8. Avoid comments on apparent content. Avoid Comments That Explain The Obvious. a) The code should be self-explanatory. A good code consisting of multi-readability variables and methods should not be required. Code Should Be Self Explanatory. Good Code with Readable Variable and Method Names Should Not Require Comments. 9. Only for the premise of the operation, the intrinsic algorithm and other write documents. Document Only Operational Assumptions, Algorithm Insights and So on. 10. Avoid the method level document. Avoid Method-Level Documentation. a) uses a large number of external documents to the API document. Use Extensive External Documentation for API Documentation. b) Method CAUTION As a prompt to other developers. Use method tips for other development. 11. Never have a hardcore value, but always declare a constant. Never Hard-Code a Numeric Value, Always Declare a constant instead. 12. Use a const modifier only for values that are constant, such as one week. Use the constant the on Nature Constants Such as the number of days of week. 13. Avoid using a const modifier for read-only variables. In this case, a Readonly modifier is used.
. Avoid using const on readonly variables for that, use the readonly directive public class myclass {public readonly int number; public myclass (int somevalue) {number = somevalue;} public const int daysinweek = 7;}. 14. Any Assume that uses ASSERT. Assert Every Assumption. A) Average, there is a line in every 5 lines. On Average, Every Fifth Line Is An assert; use system.diagnostics; object getObject () {Object obj = getObject (); debug.assert (Obj! = null); 15. Each line of code should pass through a white box test. Every Line Of Code Should Be Walked THROUGH IN A 搘 Hite Box? Testing Manner. 16. Capture only an exception that has been explicitly processed. Only Catch Exceptions for Which You Have Explicit Handling. 17. In throwing an exception's Catch statement, the initial exception is always thrown to maintain an initial incorrect stack position. in a catch statement that throws an exception, always throw the original exception to maintain stack location of original error catch (exception exception) {messagebox.show (exception.message); throw; // same as throw exception;}. 18. Avoid The return value of the error code is used as the method. 19. Avoid defining a custom anomaly class. Avoid Defining Custom Exception Classes. 20. Defines Custom Exception: When Defining Custom Exceptions: a) Inherited Derive The Custom Exception from ApplicationException. b) Provides custom serialization. Provide Custom Serialization. 21. Avoid having multiple main () methods in one program. Avoid Multiple Main () Methods In a Single assembly. 22. Only the most needed type is labeled as public, and other labeled INTERNALs. Make Only The MOST NECESSARY TYPES PUBLIC, MARK OTHERS AS INTERNAL. 23. Avoid using Friend assemblies, because this increases the coupling of the program. Avoid Friend Assemblies, as it increas Inter-assembly coupling. 24. Avoid using code dependent on assemblies run from a specific location. Avoid Code That Relies on an assembly running from a particular location. 25. Minimize the code of the application set (client EXE assembly). Use class libraries instead of the business logic layer code.
Minimize Code In Application Assemblies (Exe Client AssemBlies). Use Class Libraries Instead to Contain Business Logic. 26. Avoid providing a clear value for enumeration. Avoid Providing Explicit Values for Enums. // Correct Public Enum Color {Red, Green, Blue} // Avoid Public Enum Color {Red = 1, Green = 2, Blue = 3} 27. Avoid the specified type of enumeration. Avoid Specifying a type for an enum. // Avoid Public Enum Color: long {red, green, blue} 28. If statement is always using parentheses, even if it contains a statement. ALWAYS USE A CURLY BRACE Scope in AN IF IT CONDitions A Single Statement. 29. Avoid use?: Conditional operator. Avoid Using The Trinary Conditional Operator. 30. Avoid calling a function in a Boolean condition statement. Assign a local variable and check their values. Avoid Function Calls in Boolean Conditional Statements. Assign INTO LOCAL VARIABLES AND CHECK INTO LOCAL VARIABLES AND CHECK IN THEM: BOOL ISEVERYTHINGOK () {...} // Avoid: // Avoid: IF (ISEVERYTHINGOK ()) {...} // adopt: / / INSTEAD: BOOL OK = ISEVERYTHINGOK (); if (ok) {...} 31. Always use an array starting from 0. Always use zero-based arrays. 32. Always use a FOR cycle to explicitly initialize an array of reference types. always explicitly initialize an array of reference types using a for loop public class myclass {} myclass [] array = new myclass [100];. for (int index = 0; index Avoid Explicit Casting. Use The as Operator To Defensively Cast To a Type. DOG DOG = New Germanshepherd (); Germanshepherd Shepherd = DOG As Germanshepherd; if (Shepherd! = NULL) {...} 38. Class members have entrusted: WITH DELEGATES AS CLASS MEMBERS: a) Copy the delegated to local variables before use to avoid concurrent conflicts. Copy a delegate to a local variable before publishing to Avoid Concurrency Race Condition. b) Never check whether the delegate is empty before calling. . Always check a delegate for null before invoking it public class mysource {public event eventhandler myevent; public void fireevent () {eventhandler temp = myevent; if (temp = null!) {Temp (this, eventargs.empty);}}} 39. Do not provide public event member variables, but use event accessors. . Do not provide public event member variables use event accessors instead public class mysource {mydelegate m_someevent; public event mydelegate someevent {add {m_someevent = value;} remove {m_someevent - = value;}}}. 40. Use programming .net components The eventshelper class defined is safely published in the event. Use the eventshelper class defined in programming .Net Components to Publish Events Defensively. 41. Interface is always used. Always use interfaces. a) See Programming .NET Components, first and third chapters. See Chapter .Net Components. 42. The proportion of methods and attributes in the class and interfaces is at least 2: 1. Classes and interfaces Should Have at Least 2: 1 Ratio of Methods To Properties. 43. Avoid using a member's interface. Avoid Interfaces With One Member. 44. Try to have 3-5 members per interface. Strive to Have 3-5 MEMBERS Per interface. 45. Each interface does not have to exceed 20 members. No more Than 20 MEMBERS Per interface. A) 12 It may be the limit of the actual application. 12 IS probably a practical limit. 46. Avoid events as an interface member. Avoid Events As Interface Members. 47. Avoid using an abstract method, but use the interface instead. Avoid Abstract Methods, Use Interfaces INSTEAD. 48. Exposes the interface in the class level. Expose Interfaces On Class Hierarchies. a) See ProGramming .NET Components Chapter 3. See Chapter 3 in Programming .NET Components. 49. Priority uses a clear interface implementation. Prefer Using Explicit Interface Implementation. A) See Programming .NET Components Chapter 3. See Chapter 3 in Programming .NET Components. 50. Never assume that a type supports an interface. Protective inspection does not support the interface. never assume a type supports an interface defensively query for that interface sometype obj1; imyinterface obj2; / * some code to initialize obj1, then:.. * / obj2 = obj1 as imyinterface; if (obj2 = null!) {obj2.method1 ( );} else {// handle error in expert interface} 51. The string of the user will be rendered never useless, but the use of resources. NEVER HARDCODE STRINGS THAT WILL BE PRESENTED TO End. 52. The string that may be modified will never use, such as a connection string. NEVER HARDCODE STRINGS That Might Change Strings. 53. When building a long string, use StringBuilder, do not use String. When Building a long string, use stringbuilder, not string. 54. Avoid providing a method of providing a structure. Avoid Providing Methods On Structures. a) The parameterized constructor is encouraged. Parameterized. b) Optimist of Octa. Can Overload Operators. 55. When providing a static member variable, a static constructor is always provided. Always Provide a static constructor when providing static member variables. 56. As long as you can use the previous binding, you can use the later binding. Do Not Use Late-Binding Invocation When Early-Binding Is Possible. 57. Logs and traces for applications. Use Application Logging and Tracing. 58. Unless jumped in the Switch statement, do not use the GOTO statement. Never Use Goto Unless THROUGH. 59. Switch statement is always used to use Default for the addition. Always Have A Default Case In A Switch Statement That Asserts. Int Number = SomeMethod (); Switch (Number) {Case 1: Trace.writeline ("Case 1:"); Break; Case 2: Trace.Writeline ("Case 2 : "); Break; default: debug.assert (false); break;} 60. Unless another constructor is called in the constructor, it is not necessary to use this. do not use the this reference unless invoking another constructor from within a constructor // example of proper use of thispublic class myclass {public myclass (string message) {} public myclass (): this ( "hello") {}}. 61. Unless conflict of the membership name when calling the base class constructor, do not use the base to access the base class. do not use the base word to access base class members unless you wish to resolve a conflict with a subclasses member of the same name or when invoking a base class constructor. // example of proper use of Dan ase? public class dog {public dog (string name) {} virtual public void bark (int howlong) {}} public class germanshepherd: dog {public germanshepherd (string name): base (name) {} override public void bark (int howlong) {base.bark (howlong );}} 62. DISPOSE () and FINALIZE () methods are implemented according to Templates in Chapter 4 of Programming .NET Components. Implement Dispose () Methods Based On The Template In Chapter 4 of Programming .NET Components. 63. Avoid transition to system.object in the use of generic code, but use restrictions or AS operators. avoid casting to and from system.object in code that uses generics use constraints or the as operator instead: class someclass {} // avoid avoid:. class myclass {void somemethod (tt) {object temp = t; someclass obj = (someclass Temp;}} // correct correct: class myclass where t: someclass {void SomeMethod (tt) {someClass Obj = T;}} 64. The generic interface does not define a limit. The limitations of the interface layer can usually be replaced with a strong type. .. Do not define constraints in generic interfaces interface level-constraint can often be replaced by strong-typing public class customer {...} // avoid avoid: public interface ilist where t: customer {...} // correct correct : Public interface icustomerlist: ilist {...} 65. Do not define the limitations associated with the method in the interface. Do Not Defender Method-Specific Constraints in Interfaces. 66. In the data structure, C # generics are always prioritized. Always Prefer Using C # generics in Data Structures.3 Project Settings and Project Structure Project Settings and Project Structure 1. Always establish a project (Figure for 4 warnings. Always Build Your Project with Warning Level 4 2. Warning as an error in the publishing version (Note that this is not the default setting of VS.NET) (Figure 5). Treat Warning As Errors in Release Build (Note That Is Not The Default of vs.NET). A) Although this standard is also recommended to warn as an error in the debug version. Althoughard Recommend Treating Warnings as Well. 3. Never suppress specific compilation warnings (images). Never Suppress Specific Compiler Warnings. 4. Always explicitly explain the supported runtime versions in the application's configuration file. See Chapter 5 of Programming .NET Components. Always explicitly state your supported runtime versions in the application configuration file. See Chapter 5 in Programming .NET Components.
