C#编码好习惯,献给所有热爱c#的同学

1. 避免将多个类放在一个文件里面。

2. 一个文件应该只有一个命名空间,避免将多个命名空间放在同一个文件里面。

3. 一个文件最好不要超过500行的代码(不包括机器产生的代码)。

4. 一个方法的代码长度最好不要超过25行。

5. 避免方法中有超过5个参数的情况。使用结构来传递多个参数。

6. 每行代码不要超过80个字符。

7. 不要手工的修改机器产生的代码。

a) 如果需要编辑机器产生的代码,编辑格式和风格要符合该编码标准。

b) Use partial classes whenever possible to factor out the maintained portions.

8. 避免利用注释解释显而易见的代码。

a) 代码应该可以自解释。好的代码由可读的变量和方法命名因此不需要注释。

9. Document only operational assumptions, algorithm insights and so on.

10. 避免使用方法级的文档。

a) 使用扩展的API文档说明之。

b) 只有在该方法需要被其他的开发者使用的时候才使用方法级的注释。(在C#中就是///)

11. 不要硬编码数字的值,总是使用构造函数设定其值。

12. 只有是自然结构才能直接使用const,比如一个星期的天数。

13. 避免在只读的变量上使用const。如果想实现只读,可以直接使用readonly。

public class MyClass

{

public readonly int Number;

public MyClass(int someValue)

{

Number = someValue;

}

public const int DaysInWeek = 7;

}

14. 每个假设必须使用Assert检查

a) 平均每15行要有一次检查(Assert)

using System.Diagnostics;

object GetObject()

{…}

object obj = GetObject();

Debug.Assert(obj != null);

15. 代码的每一行都应该通过白盒方式的测试。

16. 只抛出已经显示处理的异常。

17. 在捕获(catch)语句的抛出异常子句中(throw),总是抛出原始异常维护原始错误的堆栈分配。

catch(Exception exception)

{

MessageBox.Show(exception.Message);

throw ; //和throw exception一样。

}

18. 避免方法的返回值是错误代码。

19. 尽量避免定义自定义异常类。

20. 当需要定义自定义的异常时:

a) 自定义异常要继承于ApplicationException。

b) 提供自定义的序列化功能。

21. 避免在单个程序集里使用多个Main方法。

22. 只对外公布必要的操作,其他的则为internal。

23. Avoid friend assemblies, as it increases inter-assembly coupling.

24. Avoid code that relies on an assembly running from a particular location.

25. 使应用程序集尽量为最小化代码(EXE客户程序)。使用类库来替换包含的商务逻辑。

26. 避免给枚举变量提供显式的值。

//正确方法

public enum Color

{

Red,Green,Blue

}

//避免

public enum Color

{

Red = 1,Green = 2,Blue = 3

}

27. 避免指定特殊类型的枚举变量。

//避免

public enum Color : long

{

Red,Green,Blue

}

28. 即使if语句只有一句,也要将if语句的内容用大括号扩起来。

29. 避免使用trinary条件操作符。

30. 避免在条件语句中调用返回bool值的函数。可以使用局部变量并检查这些局部变量。

bool IsEverythingOK()

{…}

//避免

if (IsEverythingOK ())

{…}

//替换方案

bool ok = IsEverythingOK();

if (ok)

{…}

31. 总是使用基于0开始的数组。

32. 在循环中总是显式的初始化引用类型的数组。

public class MyClass

{}

MyClass[] array = new MyClass[100];

for(int index = 0; index < array.Length; index++)

{

array[index] = new MyClass();

}

33. 不要提供public 和 protected的成员变量,使用属性代替他们。

34. 避免在继承中使用new而使用override替换。

35. 在不是sealed的类中总是将public 和 protected的方法标记成virtual的。

36. 除非使用interop(COM+ 或其他的dll)代码否则不要使用不安全的代码(unsafe code)。

37. 避免显示的转换,使用as操作符进行兼容类型的转换。

Dog dog = new GermanShepherd();

GermanShepherd shepherd = dog as GermanShepherd;

if (shepherd != null )

{…}

38. 当类成员包括委托的时候

a) Copy a delegate to a local variable before publishing to avoid concurrency race

condition.

b) 在调用委托之前一定要检查它是否为null

public class MySource

{

public event EventHandler MyEvent;

public void FireEvent()

{

EventHandler temp = MyEvent;

if(temp != null )

{

temp(this,EventArgs.Empty);

}

}

}

39. 不要提供公共的事件成员变量,使用事件访问器替换这些变量。

public class MySource

{

MyDelegate m_SomeEvent ;

public event MyDelegate SomeEvent

{

add

{

m_SomeEvent += value;

}

remove

{

m_SomeEvent -= value;

}

}

}

40. 使用一个事件帮助类来公布事件的定义。

41. 总是使用接口。

42. 类和接口中的方法和属性至少为2:1的比例。

43. 避免一个接口中只有一个成员。

44. 尽量使每个接口中包含3-5个成员。

45. 接口中的成员不应该超过20个。

a) 实际情况可能限制为12个

46. 避免接口成员中包含事件。

47. 避免使用抽象方法而使用接口替换。

48. 在类层次中显示接口。

49. 推荐使用显式的接口实现。

50. 从不假设一个类型兼容一个接口。Defensively query for that interface.

SomeType obj1;

IMyInterface obj2;

/* 假设已有代码初始化过obj1,接下来 */

obj2 = obj1 as IMyInterface;

if (obj2 != null)

{

obj2.Method1();

}

else

{

//处理错误

}

51. 表现给最终用户的字符串不要使用硬编码而要使用资源文件替换之。

52. 不要硬编码可能更改的基于配置的字符串,比如连接字符串。

53. 当需要构建长的字符串的时候,使用StringBuilder不要使用string

54. 避免在结构里面提供方法。

a) 建议使用参数化构造函数

b) 可以重裁操作符

55. 总是要给静态变量提供静态构造函数。

56. 能使用早期绑定就不要使用后期绑定。

57. 使用应用程序的日志和跟踪。

58. 除非在不完全的switch语句中否则不要使用goto语句。

59. 在switch语句中总是要有default子句来显示信息(Assert)。

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. 除非在构造函数中调用其他构造函数否则不要使用this指针。

// 正确使用this的例子

public class MyClass

{

public MyClass(string message )

{}

public MyClass() : this("hello")

{}

}

61. 除非你想重写子类中存在名称冲突的成员或者调用基类的构造函数否则不要使用base来访问基类的成员。

// 正确使用base的例子

public class Dog

{

public Dog(string name)

{}

virtual public void Bark( int howLong)

{}

}

public class GermanShepherd : Dog

{

public GermanShe pherd(string name): base (name)

{}

override public void Bark(int howLong)

{

base .Bark(howLong);

}

}

62. 基于模板的时候要实现Dispose()和Finalize()两个方法。

63. 通常情况下避免有从System.Object转换来和由System.Object转换去的代码,而使用强制转换或者as操作符替换。

class SomeClass

{}

//避免:

class MyClass <T>

{

void SomeMethod(T t)

{

object temp = t;

SomeClass obj = (SomeClass)temp;

}

}

// 正确:

class MyClass <T> where T : SomeClass

{

void SomeMethod(T t)

{

SomeClass obj = t;

}

}

64. 在一般情况下不要定影有限制符的接口。接口的限制级别通常可以用强类型来替换之。

public class Customer

{…}

//避免:

public interface IList <T> where T : Customer

{…}

//正确:

public interface ICustomerList : IList <Customer>

{…}

65. 不确定在接口内的具体方法的限制条件。

66. 总是选择使用C#内置(一般的generics)的数据结构。

http://www.cnblogs.com/zhangronghua/archive/2006/12/20/598386.html

时间: 2024-10-12 05:26:32

C#编码好习惯,献给所有热爱c#的同学的相关文章

良好编码风格习惯整理

1.在每个类声明之火.每个函数定义结束之后都要加空行 2.if ,for,while,do等语句自占一行,执行语句不得紧跟其后.不论执行语句有多少都加上{ },方便代码阅读,防止书写失误 3.尽可能在定义变量的同时初始化该变量(就近原则),对于头文件的指针变量最好在构造函数中赋NULL 4.'('向后紧跟,',',')',';'向前紧跟,紧跟处不留空格 5.','之后要留空格,如Function(x, y, z), 如果':'不是一行的结束符号,其后要留空格,如for (int i = 0; i

java-常见编码坏习惯

代码质量实战Any fool can write code that a computer can understand. Good programmerswrite code that humans can understand. -- Martin FowlerThe only valid measurement of Code Quality: WTFs/minute参考资料:1.<代码大全>2.<重构:改善既有代码的设计>3.<代码整洁之道>3.<Effe

我的编码习惯 - 如何应对需求变更

原文出处:晓风轻 我之前的文章 程序员你为什么这么累? 中,我个人观点是加班原因是编码质量占了大部分因素,但是不少同学都不认为是代码质量导致的加班,都认为是不断的需求改动导致的加班.这位同学,说的好像别人的需求就不会变动似的!谁的需求不改动啊?不改动的能叫需求吗?哈哈. 先看几个程序员的段子娱乐一下 杀一个程序员不需要用枪,改三次需求就可以了. 看一个宫保鸡丁的段子娱乐一下:这TM就是设计师不想改图的真正原因!!! 客户被绑,蒙眼,惊问:"想干什么?"对方不语,鞭笞之,客户求饶:&qu

学习笔记之--高效程序员的45个习惯

有本关于敏捷开发方面的书非常不错<高效程序员的45个习惯-敏捷开发修炼之道>,Venkat Subramaniam和Andy Hunt著,该书简短.易读.精炼.深入,深刻且实用.对于想要采用敏捷方法的人很有价值.此书通过常理和经验,阐述了为什么应该在项目中实用敏捷方法.更难得的是,这些行之有效的实战经验,竟然从一本书中得到了.如果能拿这些习惯在项目中一以贯之,肯定会受益匪浅.下本罗列该书这45个习惯,一并列出其中的Key Point. -----------------------------

源代码安全的开发习惯!

我非常荣幸在过去的几年中曾经与数千位出色的开发人员一起工作,他们希望了解如何编写更安全的软件.在此期间,我也从构建安全系统方面表现出色的人员那里学到了很多东西,这使我开始思考一个问题.我在想“安全开发人员”之间是否有共同的技能或习惯.答案是当然有!本文介绍了安全代码开发人员之间共有的一系列习惯. 目前我可以肯定的一点是,任何看过这篇文章的人都会立即发现自己不具备的习惯.这非常好.我知道除此以外还有其他好的想法.这里只是列出我所观察到的!因此,下面介绍的是我在这几年中注意到的几种典型习惯. 习惯

编码规范 -- 如何应对需求变更

如何应对需求变更 现在的程序员为什么这么累,其实很大程度上来说是加班原因使编码质量占了大部分因素,但是不少同学都不认为是代码质量导致的加班,都认为是不断的需求改动导致的加班.但是话又说回来,谁的需求不改动啊?不改动的能叫需求吗? 先看个程序员的段子娱乐一下 客户被绑,蒙眼,惊问:"想干什么?" 对方不语,鞭笞之,客户求饶:"别打,要钱?" 又一鞭,"十万够不?" 又一鞭,"一百万?" 又一鞭.客户崩溃:"你们TMD到

新年计划(参考)

新年计划 还是给自己一个计划. 新年规划,还是按照我的观念,先生活后工作: 1.首要大事应该是要搞定每次打电话回家父母都要关心的事情了.但愿吧,自己不急,感觉时间大把,但是父母以他们的观念来看,已经等不及了. 2.从今年开始,每年孝敬父母一个月的工资,算是每年为父母工作一个月吧. 3.职业发展上能够再上一层楼.至于是什么就不说了,心里有数. 4.开始学会理财,08年底和09年底都把自己的所有支出统计了一次,发现工资的收入几乎是和支出相等的,没有什么剩余.看着一堆的支出项,却又不知道花往何处了.今

微信小程序豆瓣电影项目的改造过程经验分享

在学习微信小程序开发过程中,一部分的难点是前端逻辑的处理,也就是对前端JS的代码编辑:一部分的难点是前端界面的设计展示:本篇随笔基于一个豆瓣电影接口的小程序开源项目进行重新调整,把其中遇到的相关难点和改进的地方进行讨论介绍,希望给大家提供一个参考的思路,本篇随笔是基于前人小程序的项目基础上进行的改进,因此在开篇之前首先对原作者的辛劳致敬及感谢. 1.豆瓣电影接口的小程序项目情况 豆瓣电影接口提供了很多相关的接口给我们使用,豆瓣电影接口的API地址如下所示:https://developers.d

《代码整洁之道》读后感

众所周知,软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关.这一点,无论是敏捷开发派还是传统开发派,都不得不承认.<代码整洁之道>提出一种观念:代码质量与其整洁度成正比.干净的代码,既在质量上较为可靠,也为后期维护.升级奠定了良好的基础.作为编程领域的佼佼者,这些实践在<代码整洁之道>中体现为一条条规则(或称“启示”),并辅以来自现实项目的正.反两面的范例.只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量.以上便是<代码整洁之道>这本书的内容简介,