没有合适的资源？快使用搜索试试~ 我知道了~
### C# 编码规范详解 #### 概述 C# 是一种现代、面向对象的编程语言，由微软开发并在 .NET 平台上运行。为了提高软件的质量、可维护性和可读性，制定一套标准的编码规范至关重要。本文将根据提供的文件信息，详细解析一份 C# 编码规范的核心内容及其重要性。 #### 文件背景 这份文档由飞利浦医疗系统（Philips Medical Systems）发布，版本号为 XJS155-8301/1.3，日期为 2005 年 5 月 19 日。作者为 Vic Hartog 和 Dennis Doomen，并由 CCBCodingStandards 授权。该规范旨在通过一系列规则和建议来促进代码的可靠性、可维护性，并避免错误和浪费的实践。 #### 主要目标 - **错误避免**：特别关注那些难以发现的错误或 bug。 - **可维护性**：通过推广一些经过验证的设计原则以及统一的编码风格来提升代码的可维护性。 - **性能优化**：通过避免浪费性的做法来提高程序性能。 #### 规范适用范围 此规范适用于飞利浦医疗系统的内部使用，并且可以被外部用户“原样”使用，但需遵循相关的许可条款。 #### 详细规范内容 ##### 1. 命名规范 - **命名规则**：变量、方法、类等的命名应清晰、明确，反映其功能和用途。 - **大小写约定**：例如，类名首字母大写，变量名采用 camelCase 等。 - **匈牙利记法**：虽然不强制要求，但在一些特定情况下允许使用，以增强代码的可读性和一致性。 ##### 2. 注释与文档 - **代码注释**：对复杂的逻辑或算法进行适当的注释，帮助其他开发者理解。 - **文档编写**：为公共接口、类和方法编写 XML 文档注释，便于生成 API 文档。 - **避免冗余注释**：不要对显而易见的代码添加注释，这反而会降低代码的可读性。 ##### 3. 结构化编程 - **模块化设计**：提倡将大型项目分解成小型、易于管理的模块。 - **单一职责原则**：每个类或方法只负责一个功能，避免过于臃肿。 - **异常处理**：正确处理异常情况，避免程序崩溃并提供有用的错误信息。 ##### 4. 类和对象设计 - **继承与多态**：合理使用继承关系，并通过多态实现灵活的代码复用。 - **封装**：保护数据成员不受外部直接访问，通过公共方法提供访问接口。 - **接口与抽象类**：使用接口定义行为规范，抽象类作为基类提供部分实现。 ##### 5. 性能优化 - **循环优化**：减少循环内的计算开销，避免不必要的内存分配。 - **缓存结果**：对于重复调用的方法，考虑缓存计算结果以减少重复计算。 - **延迟加载**：对于大型数据集，使用懒加载技术按需加载数据，节省资源。 ##### 6. 常见问题与注意事项 - **空引用检查**：在使用对象之前进行空引用检查，避免运行时错误。 - **资源释放**：确保所有资源都能得到及时释放，避免内存泄漏。 - **安全性考虑**：防止 SQL 注入、跨站脚本等安全漏洞。 #### 结论 此 C# 编码规范不仅覆盖了编码风格，还包括了诸多实用的建议和注意事项，有助于开发者编写出高质量、可维护的代码。对于从事 C# 开发工作的工程师来说，遵循这一规范不仅能提高工作效率，还能有效减少潜在的错误和隐患。
资源详情
资源评论
Philips Medical Systems
TRAD Philips’ proprietary, ? 2003 Philips Electronics N.V. All rights reserved
Coding Standard: C#
Philips Medical Systems - Software / SPI
AUTHOR: Vic Hartog and Dennis Doomen
DOC. ID: XJS155-8301
REV. LEVEL: 1.3
DATE: 2005-05-19
STATUS: Authorized
Authorization by: CCB Coding Standards
Reviewers: CCB Coding Standards
Commentators: Paul Jansen (TIOBE Software)
Copy: Archive, Bangalore, Cleveland
Doc.file: gemrcsharpcs_ext.doc [ saved: 03 Oct 2005 23:09 ]
Reviewers: You will be invited for a review meeting. Draft:
Commentators: Comments within 2 weeks to author.
Concept: Reviewers: Comments within 2 weeks to author.
Authorized: This is your personal copy. Destroy all previous levels
XJS155-8301 / 1.3 Coding Standard: C# Page 2 of 48
For External Use 2005-05-19
TRAD Philips’ proprietary, © 2003 Philips Electronics N.V. All rights reserved
Abstract
This coding standard for the C# language is mandatory for PMS. The objective of this coding standard is to have
a positive effect on
??Avoidance of errors/bugs, especially the hard-to-find ones.
??Maintainability, by promoting some proven design principles.
??Maintainability, by requiring or recommending a certain unity of style.
??Performance, by dissuading wasteful practices.
??Rules and recommendations are given that promote reliability and maintainability.
External Use of this Document
The C# coding standard as defined by Philips Medical Systems and published via the TIOBE website
(www.tiobe.com) may be used "as-is" by any interested party.
You may copy, adapt, and redistribute this document for non-commercial use or for your own internal use in a
commercial setting. However, you may not republish this document, nor may you publish or distribute any
adaptation of this document for other than non-commercial use or your own internal use, without first obtaining
express written approval from Philips Medical Systems. Philips Medical Systems will not be liable for any direct,
indirect, special or consequential damages arising out of any use of the document or the performance or
implementation of the contents thereof.
Please send questions and suggestions about the C# coding standard and/or its code checker ClockSharp to
info@tiobe.com.
XJS155-8301 / 1.3 Coding Standard: C# Page 3 of 48
For External Use 2005-05-19
TRAD Philips’ proprietary, © 2003 Philips Electronics N.V. All rights reserved
1. Introduction ..........................................................................................................7
1.1. Objective .................................................................................................................................. 7
1.2. Scope .......................................................................................................................................7
1.3. Rationale .................................................................................................................................. 7
1.3.1. Sources of inspiration ............................................................................................................... 7
1.3.2. Contrast with C++.................................................................................................................... 8
1.4. Applicability............................................................................................................................. 8
1.5. History ..................................................................................................................................... 8
1.6. Status of document ...................................................................................................................8
1.7. Notational conventions.............................................................................................................. 9
1.7.1. Rule..........................................................................................................................................9
1.7.2. Recommendation.......................................................................................................................9
1.7.3. Checkable.................................................................................................................................9
1.7.4. Tabular overview......................................................................................................................9
1.7.5. Examples.................................................................................................................................. 9
1.8. Definition of terms and abbreviations ........................................................................................ 9
1.9. References................................................................................................................................ 9
2. General rules.......................................................................................................11
2.1. Overview................................................................................................................................ 11
2.2. Rules and Recommendations................................................................................................... 11
2.2.1. Rule 2@102: Every time a recommendation is not followed, this must have a good reason. ...... 11
2.2.2. Rule 2@105: Do not mix code from different providers in one file ........................................... 11
3. Naming conventions............................................................................................ 12
3.1. Overview................................................................................................................................ 12
3.2. Rules and Recommendations................................................................................................... 13
3.2.1. Rec. 3@101: Use US-English for naming identifiers................................................................ 13
3.2.2. Rule 3@102: Use Pascal and Camel casing for naming identifiers............................................ 13
3.2.3. Rule 3@103: Do not use Hungarian notation or add any other type identification to identifiers. 13
3.2.4. Rule 3@104: Do not prefix member fields............................................................................... 13
3.2.5. Rule 3@105: Do not use casing to differentiate identifiers. ..................................................... 13
3.2.6. Rec. 3@106: Use abbreviations with care................................................................................ 14
3.2.7. Rule 3@107: Do not use an underscore in identifiers............................................................... 14
3.2.8. Rec. 3@108: Name an identifier according to its meaning and not its type................................ 14
3.2.9. Rule 3@109: Name namespaces according to a well-defined pattern........................................ 14
3.2.10. Rule 3@110: Do not add a suffix to a class or struct name............................................. 15
3.2.11. Rec. 3@111: Use a noun or a noun phrase to name a class or struct............................... 15
3.2.12. Rule 3@113: Prefix interfaces with the letter I. ...................................................................... 15
3.2.13. Rec. 3@120: Use similar names for the default implementation of an interface......................... 15
3.2.14. Rule 3@122: Suffix names of attributes with Attribute................................................... 15
3.2.15. Rule 3@201: Do not add an Enum suffix to an enumeration type. ........................................... 15
3.2.16. Rule 3@202: Use singular names for enumeration types.......................................................... 15
3.2.17. Rule 3@203: Use a plural name for enumerations representing bitfields................................... 15
3.2.18. Rec. 3@204: Do not use letters that can be mistaken for digits, and vice versa......................... 16
3.2.19. Rule 3@301: Add EventHandler to delegates related to events.......................................... 16
3.2.20. Rule 3@302: Add Callback to delegates related to callback methods................................... 16
3.2.21. Rule 3@303: Do not add a Callback or similar suffix to callback methods.......................... 16
3.2.22. Rec. 3@304: Use a verb (gerund) for naming an event............................................................. 16
3.2.23. Rule 3@305: Do not add an Event suffix (or any other type-related suffix) to the name of an
event....................................................................................................................................... 16
3.2.24. Rule 3@306: Use an –ing and –ed form to express pre-events and post-events...................... 16
3.2.25. Rule 3@307: Prefix an event handler with On........................................................................ 17
XJS155-8301 / 1.3 Coding Standard: C# Page 4 of 48
For External Use 2005-05-19
TRAD Philips’ proprietary, © 2003 Philips Electronics N.V. All rights reserved
3.2.26. Rule 3@401: Suffix exception classes with Exception...................................................... 17
3.2.27. Rule 3@402: Do not add code-archive related prefixes to identifiers. ....................................... 17
3.2.28. Rule 3@501: Name DLL assemblies after their containing namespace..................................... 17
3.2.29. Rule 3@502: Do not add MR building block prefixes to source files........................................ 17
3.2.30. Rule 3@503: Use Pascal casing for naming source files........................................................... 17
3.2.31. Rule 3@504: Name the source file to the main class................................................................ 17
3.2.32. Rule 3@505: Only use the this. construction to avoid a name clash..................................... 17
4. Comments and embedded documentation.........................................................18
4.1. Overview................................................................................................................................ 18
4.2. Rules and Recommendations................................................................................................... 18
4.2.1. Rule 4@101: Each file shall contain a header block................................................................. 18
4.2.2. Rule 4@103: Use // for comments. ....................................................................................... 18
4.2.3. Rule 4@105: All comments shall be written in US English. ..................................................... 18
4.2.4. Rule 4@106: Use XML tags for documenting types and members. .......................................... 18
4.2.5. Rec. 4@110: Use #region to group non-public members..................................................... 19
5. Object lifecycle ...................................................................................................20
5.1. Overview................................................................................................................................ 20
5.2. Rules and recommendations .................................................................................................... 20
5.2.1. Rec. 5@101: Declare and initialize variables close to where they are used................................ 20
5.2.2. Rec. 5@102: If possible, initialize variables at the point of declaration..................................... 20
5.2.3. Rule 5@105: Use a const field to define constant values. ..................................................... 20
5.2.4. Rec. 5@106: Use a public static read-only field to define predefined object instances............... 20
5.2.5. Rec. 5@107: Set a reference field to null to tell the GC that the object is no longer needed.... 21
5.2.6. Rule 5@108: Do not ‘shadow’ a name in an outer scope.......................................................... 21
5.2.7. Rec. 5@111: Avoid implementing a destructor........................................................................ 21
5.2.8. Rule 5@112: If a destructor is needed, also use GC.SuppressFinalize........................ 21
5.2.9. Rule 5@113: Implement IDisposable if a class uses unmanaged or expensive resources.... 23
5.2.10. Rule 5@114: Do not access any reference type members in the destructor................................ 24
5.2.11. Rule 5@116: Always document when a member returns a copy of a reference type or array..... 24
6. Control flow ........................................................................................................25
6.1. Overview................................................................................................................................ 25
6.2. Rules and Recommendations................................................................................................... 25
6.2.1. Rule 6@101: Do not change a loop variable inside a for loop block....................................... 25
6.2.2. Rec. 6@102: Update loop variables close to where the loop condition is specified.................... 25
6.2.3. Rule 6@103: All flow control primitives (if, else, while, for, do, switch) shall be
followed by a block, even if it is empty.................................................................................... 25
6.2.4. Rule 6@105: All switch statements shall have a default label as the last case label...... 25
6.2.5. Rule 6@106: An else sub-statement of an if statement shall not be an if statement without
an else part.......................................................................................................................... 25
6.2.6. Rec. 6@109: Avoid multiple or conditional return statements. ............................................ 26
6.2.7. Rec. 6@112: Do not make explicit comparisons to true or false....................................... 26
6.2.8. Rule 6@115: Do not access a modified object more than once in an expression....................... 26
6.2.9. Rec. 6@118: Do not use selection statements (if, switch) instead of a simple assignment or
initialization............................................................................................................................ 26
7. Object oriented programming ...........................................................................28
7.1. Overview................................................................................................................................ 28
7.2. Rules and Recommendations................................................................................................... 28
7.2.1. Rule 7@101: Declare all fields (data members) private...................................................... 28
7.2.2. Rec. 7@102: Provide a default private constructor if there are only static methods and
properties on a class................................................................................................................ 29
7.2.3. Rec. 7@105: Explicitly define a protected constructor on an abstract base class......... 29
XJS155-8301 / 1.3 Coding Standard: C# Page 5 of 48
For External Use 2005-05-19
TRAD Philips’ proprietary, © 2003 Philips Electronics N.V. All rights reserved
7.2.4. Rec. 7@201: Selection statements (if-else and switch) should be used when the control
flow depends on an object’s value; dynamic binding should be used when the control flow
depends on the object’s type.................................................................................................... 29
7.2.5. Rule 7@301: All variants of an overloaded method shall be used for the same purpose and have
similar behavior...................................................................................................................... 29
7.2.6. Rec. 7@303: If you must provide the ability to override a method, make only the most complete
overload virtual and define the other operations in terms of it................................................... 29
7.2.7. Rec. 7@401: Specify methods using preconditions, postconditions, exceptions; specify classes
using invariants....................................................................................................................... 30
7.2.8. Rec. 7@402: Use C# to describe preconditions, postconditions, exceptions, and class invariants.30
7.2.9. Rule 7@403: It shall be possible to use a reference to an object of a derived class wherever a
reference to that object’s base class object is used.................................................................... 31
7.2.10. Rec. 7@501: Do not overload any ‘modifying’ operators on a class type. ............................ 31
7.2.11. Rule 7@502: Do not modify the value of any of the operands in the implementation of an
overloaded operator................................................................................................................. 31
7.2.12. Rec. 7@503: If you implement one of operator==(), the Equals method or
GetHashCode(), implement all three. ................................................................................ 31
7.2.13. Rec. 7@504: Use a struct when value semantics are desired............................................... 31
7.2.14. Rule 7@601: Allow properties to be set in any order. .............................................................. 32
7.2.15. Rec. 7@602: Use a property rather than a method when the member is a logical data member.. 32
7.2.16. Rec. 7@603: Use a method rather than a property when this is more appropriate. .................... 32
7.2.17. Rule 7@604: Do not create a constructor that does not yield a fully initialized object............... 32
7.2.18. Rule 7@608: Always check the result of an as operation........................................................ 32
7.2.19. Rec. 7@610: Use explicit interface implementation only to prevent name-clashing or to support
optional interfaces................................................................................................................... 32
8. Exceptions ...........................................................................................................34
8.1. Overview................................................................................................................................ 34
8.2. Rules and Recommendations................................................................................................... 34
8.2.1. Rule 8@101: Only throw exceptions in exceptional situations.................................................. 34
8.2.2. Rule 8@102: Do not throw exceptions from inside destructors................................................. 34
8.2.3. Rec. 8@103: Only re-throw exceptions when you want to specialize the exception................... 34
8.2.4. Rule 8@104: List the explicit exceptions a method or property can throw................................ 34
8.2.5. Rule 8@105: Always log that an exception is thrown. ............................................................. 35
8.2.6. Rec. 8@106: Allow callers to prevent exceptions by providing a method or property that returns
the object’s state. .................................................................................................................... 35
8.2.7. Rec. 8@107: Use standard exceptions..................................................................................... 35
8.2.8. Rec. 8@108: Throw informational exceptions. ........................................................................ 35
8.2.9. Rule 8@109: Throw the most specific exception possible. ....................................................... 35
8.2.10. Rule 8@110: Only catch the exceptions explicitly mentioned in the documentation................... 35
8.2.11. Rule 8@201: Derive custom exceptions from ApplicationException......................... 36
8.2.12. Rec. 8@202: Provide common constructors for custom exceptions. ......................................... 36
8.2.13. Rule 8@203: Avoid side-effects when throwing recoverable exceptions. .................................. 36
8.2.14. Rule 8@204: Do not throw an exception from inside an exception constructor. ........................ 36
9. Delegates and events...........................................................................................37
9.1. Overview................................................................................................................................ 37
9.2. Rules and Recommendations................................................................................................... 37
9.2.1. Rule 9@101: Do not make assumptions on the object’s state after raising an event................... 37
9.2.2. Rule 9@102: Always document from which thread an event handler is called........................... 37
9.2.3. Rec. 9@103: Raise events through a protected virtual method.................................................. 37
9.2.4. Rule 9@104: Use the sender/arguments signature for event handlers........................................ 38
9.2.5. Rec. 9@105: Implement add/remove accessors if the number of handlers for an event must be
limited. ................................................................................................................................... 38
剩余48页未读，继续阅读
安全验证
文档复制为VIP权益，开通VIP直接复制
信息提交成功
评论3
最新资源