C代码规范.docx

上传人:b****6 文档编号:5284021 上传时间:2022-12-14 格式:DOCX 页数:6 大小:17.48KB
下载 相关 举报
C代码规范.docx_第1页
第1页 / 共6页
C代码规范.docx_第2页
第2页 / 共6页
C代码规范.docx_第3页
第3页 / 共6页
C代码规范.docx_第4页
第4页 / 共6页
C代码规范.docx_第5页
第5页 / 共6页
点击查看更多>>
下载资源
资源描述

C代码规范.docx

《C代码规范.docx》由会员分享,可在线阅读,更多相关《C代码规范.docx(6页珍藏版)》请在冰豆网上搜索。

C代码规范.docx

C代码规范

 

36ng15ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddC#代码规范

1.类名使用Pascal大小写形式

publicclassHelloWorld{...}

2.方法(属性)使用Pascal大小写形式

publicclassHelloWorld{voidsayHello(stringname){...}}

3.用Camel规则来命名局部变量和方法的参数.

classHelloWorld

{

inttoTalount=0;

voidSayHello(stringname)

{

stringfullMessage="Hello"+name;...

}

}

4.用有意义的,描述性的词语来命名变量

尽量不要使用缩写。

用name,address,salary等代替nam,addr,sal(理解不清的要注释)

用于循环迭代的变量例外:

for(inti=0;i

5.所有的成员变量前加前缀m_,常量每个字符都大写

publicclassDatabase

{

publicstringm_connectionString;

}

6.接口的名称加前缀I.

interfaceICompare

{

intcompare();

}

7.自定义的特性以Attribute结尾

publicclassAuthorAttribute:

Attribute

{

}

8.自定义的异常以Exception结尾

publicclassAppException:

Exception

{

}

9.方法的命名.一般将其命名为动宾短语.

ShowDialog()

CreateFile()

GetPath()

 

10.文件名要和类名匹配

例如,对于类HelloWorld,相应的文件名应为HelloWorld.cs(或,HelloWorld.vb)

目录及文件的名字要取得有意义

 

12.缩进和间隔

●缩进用TAB.不用SPACES.。

●注释需和代码对齐.。

●花括弧({})需和括号外的代码对齐。

●用一个空行来分开代码的逻辑分组.

●Iftry涉及{…}代码块要用一句话注释来简单解释

13.属性的使用(安全控制)

 publicstringName

 {

  get{returnthis.name;}

  set{this.name=value;}

 }

如果你要在类外部给一个变量赋值的,要使用属性来赋值,这样具有更高的安全性

14.使用某个控件的值时,尽量命名局部变量.

15.把引用的系统的namespace和自定义或第三方的分开.

16.目录结构中要反应出namespace的层次.

良好的编程习惯

●避免使用大文件。

如果一个文件里的代码超过300~400行,必须考虑将代码分开到不同类中。

●避免写太长的方法。

一个典型的方法代码在1~25行之间。

如果一个方法发代码超过25行,应该考虑将其分解为不同的方法。

●方法名需能看出它作什么。

别使用会引起误解的名字。

如果名字一目了然,就无需用文档来解释方法的功能了。

好:

voidSavePhoneNumber(stringphoneNumber)

{//Savethephonenumber.}

不好:

//Thismethodwillsavethephonenumber.

voidSaveData(stringphoneNumber)

{//Savethephonenumber.}

别在程序中使用固定数值,用常量代替。

●别用字符串常数。

用资源文件。

●避免使用很多成员变量。

声明局部变量,并传递给方法。

不要在方法间共享成员变量。

如果在几个方法间共享一个成员变量,那就很难知道是哪个方法在什么时候修改了它的值。

全局静态变量最好只读取,不要修改。

●必要时使用enum。

别用数字或字符串来指示离散值。

好:

enumMailType

{Html,PlainText,Attachment}

voidSendMail(stringmessage,MailTypemailType)

{

switch(mailType)

{caseMailType.Html:

//Dosomethingbreak;

caseMailType.PlainText:

//Dosomething

break;

caseMailType.Attachment:

//Dosomethingbreak;

default:

//Dosomethingbreak;

}

}

不好:

voidSendMail(stringmessage,stringmailType)

{

switch(mailType)

{case"Html":

//Dosomething

break;

case"PlainText":

//Dosomething

break;

case"Attachment":

//Dosomethingbreak;

default:

//Dosomethingbreak;

}

}

●别把成员变量声明为public或protected。

都声明为private

●不在代码中使用具体的路径和驱动器名。

使用相对路径,并使路径可编程。

●错误消息需能帮助用户解决问题。

永远别用象"应用程序出错","发现一个错误"等错误消息。

而应给出象"更新数据库失败。

请确保登陆id和密码正确。

"的具体消息

●显示给用户的消息要简短而友好。

但要把所有可能的信息都记录下来,以助诊断问题。

注释

●别每行代码,每个声明的变量都做注释。

●在需要的地方注释。

可读性强的代码需要很少的注释。

如果所有的变量和方法的命名都很有意义,会使代码可读性很强并无需太多注释。

●行数不多的注释会使代码看起来优雅。

但如果代码不清晰,可读性差,那就糟糕。

●如果应为某种原因使用了复杂艰涩的原理,为程序配备良好的文档和重分的注释。

●对一个数值变量采用不是0,-1等的数值初始化,给出选择该值的理由。

●简言之,要写清晰,可读的代码以致无须什么注释就能理解。

 

以下可看可不看

异常处理

●不要“捕捉了异常却什么也不做“。

如果隐藏了一个异常,你将永远不知道异常到底发生了没有。

●发生异常时,给出友好的消息给用户,但要精确记录错误的所有可能细节,包括发生的时间,和相关方法,类名等。

●只捕捉特定的异常,而不是一般的异常。

好:

voidReadFromFie(stringfileName)

{

try{//readfromfile.}

catch(FileIOExceptionex)

{

//logerror.

//re-throwexceptiondependingonyourcase.throw;

}

}

不好:

voidReadFromFile(stringfileName)

{

try{//readfromfile.}

catch(Exceptionex)

{

//Catchinggeneralexceptionisbad...wewillneverknowwhetherit

//wasafileerrororsomeothererror.

//Hereyouarehidinganexception.

//Inthiscasenoonewilleverknowthatanexceptionhappened.return"";

}

}

●你可以用应用程序级(线程级)错误处理器处理所有一般的异常。

遇到”以外的一般性错误“时,此错误处理器应该捕捉异常,给用户提示消息,在应用程序关闭或用户选择”忽略并继续“之前记录错误信息。

●不必每个方法都用try-catch。

当特定的异常可能发生时才使用。

比如,当你写文件时,处理异常FileIOException.

●别写太大的try-catch模块。

如果需要,为每个执行的任务编写单独的try-catch模块。

这将帮你找出哪一段代码产生异常,并给用户发出特定的错误消息

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 表格模板 > 合同协议

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1