C# 注释规范

第一篇:C# 解释规范

       C# 解释(Comment)规范

       解释规范包括:模块(类)解释规范、类的属性、方法解释规范、代码间解释

       1.模块(类)解释规范

       模块开始必须以以下形式书写模块解释:

       ///

       ///模块编号:<模块编号,可以引用系统设计中的模块编号> ///作用:<对此类的描述,可以引用系统设计中的描述> ///:中文名

       ///编写日期:<模块创建日期,格式:YYYY-MM-DD> ///

如果模块有修改,则每次修改必须添加以下解释:

       ///

///Log编号:

       ///修改描述:<对此修改的描述> ///:修改者中文名

       ///修改日期:<模块修改日期,格式:YYYY-MM-DD> ///

       2.类属性解释规范

       在类的属性必须以以下格式编写属性解释:

       ///

///属性说明 ///

       3.方法解释规范

       在类的方法声明前必须以以下格式编写解释

       ///

/// 说明:<对该方法的说明>

       ///

///

       "><参数说明> /// ///<对方法返回值的说明,该说明必须明确说明返回的值代表什么含义> ///

       4.代码间解释规范

       代码间解释分为单行解释和多行解释:

       单行解释: //<单行解释>

       多行解释: /*多行解释1 多行解释2 多行解释3*/

       代码中遇到语句块时必须添加解释(if,for,foreach,……),添加的解释必须能够说明此语句块的作用和实现手段(所用算法等等)。

       详细介绍见:

       http://

第二篇:C#编码规范及命名规范

       山东锋士自动化系统有限公司

       C# 编码规范

       指导规则和最佳实践 Version 1.0

       董毅 2022/4/26

       第一条 编码的风格和细节要求

       编码风格

       至少在单一文件中缩进和风格要保持一致,同一行中内容不要太长,最好不要大于10个单词。不要随意地或者以容易混淆作用域嵌套关系的方式放置括号,要尽量遵循每个文件中已经使用的体例。

       命名约定和规范

       1.不要使用晦涩的名称,起名要简单易懂

       a.避免使用单字母做变量名,比如:i 或者 t。应使用index或者temp进行替代 b.不要缩写单词,比如用num代替number 2.使用全大写字母表示宏,常量,如:LIKE_THIS 3.类,函数和枚举的名称的单词首字母大写,如:LikeThis public class SomeClass {

       const int DefaultSize = 100;public void SomeMethod(){ } } 4.变量的首字母小写,其他单词首字母大写,如:likeThis void MyMethod(int someNumber){ int number;} 5.接口的第一个字母用I开头

       interface IMyInterface {...} 6.私有成员变量以m_开头,剩余内容遵从首字母大写的规范

       public class SomeClass { private int m_Number;} 7.属性类以Attribute做后缀,异常类以Exception做后缀

       8.命名方法以【动词】-【目标】组成,比如:ShowDialog()

       9.拥有返回值的方法应该以返回值描述其方法名,比如:GetObjectState()10.总是使用C#的预定义类型,而不是System命名空间中的别名,比如:

       object 而不是

       Object string 而不是

       String int

       而不是

       Int32 11.对于基类,类型描述采用大写字母。当处理.NET中的类型时才保留后缀Type //正确

       public class LinkedList { } //避免

       public class LikedList { }

       12.使用有意义的名字空间,比如项目名称或者公司名称 13.避免使用类的全称,而是使用using语句进行引用 14.避免在命名空间内使用using语句

       15.将所有framework命名空间吗放在一起,后面放自定义或第三方的命名空间名

       using System;using System.Collections;using System.ComponentModel;using System.Data;using MyCompany;using MyControls;

       16.采用委托推断,不要显式实例化委托

       delegate void SomeDelegate();public void SomeMethod(){ } SomeDelegate someDelegate = SomeMethod;

       17.缩进至少在同一文件中要保持统一风格,解释缩进和其解释的代码在同一层次 18.所有解释要经过认真检查,不要有不明语义或者错别字 19.所有成员变量应该定义在前面,和属性或方法间空开一行

       public class MyClass { int m_Number;string m_Name;

       public void SomeMethod1(){ } public void SomeMethod2(){ } }

       20.局部变量的定义尽可能靠近它的初次使用 21.文件名应该体现其包含的类

       22.当使用partial类型且每部分分配一个文件时,以类名 逻辑部分的方式来命名文件

       //MyClass.cs public partial class MyClass { } //MyClass.Designer.cs public partial class MyClass { } 23.做大括号总是放在新行中

       24.匿名方法模仿普通方法布局,但是大括号要和委托声明对其

       delegate void SomeDelegate(string someString);//正确

       void InvokeMethod(){ SomeDelegate someDelegate = delegate(string name){ MessageBox.Show(name);};someDelegate(“Juval”);} //错误

       void InvokeMethod(){ SomeDelegate someDelegate = delegate(string name){ MessageBox.Show(name);};someDelegate(“Juval”);}

       25.没有参数的匿名方法使用空括号,仅当匿名方法被用于任何委托时才可以省略括号

       delegate void SomeDelegate();//正确

       SomeDelegate someDelegate1 = delegate(){ MessageBox.Show(“Hello”);};//错误

       SomeDelegate someDelegate1 = delegate { MessageBox.Show(“Hello”);};

       26.在使用Lambda表达式时,模仿一般的方法规范。

       delegate void SomeDelegate(string someString);

       SomeDelegate someDelegate =(name)=> { Trace.WriteLine(name);MessageBox.Show(name);};

       27.当内联Lambda表达式仅包含一个简单的语句时,应避免多语句或者返回语句出现在大括号中。可以简单使用小括号表达:

       delegate void SomeDelegate(string someString);

       void MyMethod(SomeDelegate someDelegate){ }

       //正确

       MyMethod(name=>MessageBox.Show(name));

       //错误

       MyMethod((name)=>{Trace.WriteLine(name);MessageBox.Show(name);});解释

       编写有用的解释,不要在解释中重复写代码语义。应该编写的是解释方法和原理的说明性解释。

       函数

       不要在一个函数中包含太多内容,函数的功能要简单,短小,使人更容易理解,也有利于防错。

       第二条 尽量在代码中不包含被警告的内容

       高度重视警告:使用编译器的最高警告级别。构建尽量做到干净利落(没有警告)。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。

       即使程序一开始似乎能够正确运行,也还是要这样做。即使你能够肯定警告是良心的,仍然要这样做。因为良性警告的背后可能隐藏着未来指向真正危险的警告。

       项目设置和项目结构

       1. 总是以4级警告建立项目

       2. 在发布版中将警告当作错误(注意这不是VS.NET的缺省设置)

       3. 永远不要抑制特定的编译警告

       4. 总是在应用程序的配置文件中显式地说明支持的运行时版本

       <?xml version=“1.0”?>

        5. 避免显式的自定义版本改向和绑定到CLR程序集

       6. 不要在AssemblyInfo.cs中放任何逻辑。除了在AssemblyInfo.cs中,不要在任何文件中放程序集属性(应包括公司名称、描述、版权等)7. 所有程序集应该使用相对路径引用 8. 不允许在程序集中循环引用

       9. 努力对同一逻辑应用程序中(通常是一个解决方案)的所有程序集和客户端使用统一的版本号

       10.将Visual Studio.NET应用配置文件命名为App.config,并将其包括在项目中 11. 将Visual Studio.NET缺省的项目结构改为标准的布局,对项目文件夹和文件应用统一的结构 12. 一个发布版本应该包含Debug标记

       第三方头文件

       无法修改的库头文件可能包含引起警告的构造。如果这样,可以用自己的包含原头文件的版本将此文件包装起来,并有选择的为该作用域关闭警告,然后在整个项目的其他地方包含此包装文件。

       代码中尽量不包含未使用的函数,变量

       经确认确实不需要使用的函数,变量(不包括为未来使用而设的占位符),可以进行删除处理。

       不要遗漏return语句

       PS:例外情况

       有时候编译器可能会发出一些确实无意义的警告。这些警告要经过团队确认后尽量在局部进行屏蔽,但要做出明确的解释,说明为什么必须禁用。

       第三条 使用自动构建系统 第四条 使用版本控制系统

       应确保每次提交的代码都可以构建成功。

       第五条 定期进行代码审查

       互相阅读彼此的代码不但可以尽快提高自己的编码水平,也可以相互借鉴更好的方法。

       第六条 一个实体应该只有一个紧凑的职责

       一次只解决一个问题:只给一个实体(变量、类、函数、名称空间、模块和库)赋予一个定义良好的职责。应该只选择目的单一的函数,小而且目的单一的类,和边界清晰的紧凑模块。

       应该用较小的低层抽象构建更高层次的抽象,要避免将几个低层抽象集合成一个较大的低层次抽象聚合体。用几个简单的行为来实现一个复杂的行为,比反其道而行之更加容易。

       第七条 正确,简单和清晰第一

       软件简单为美:正确优于速度,简单优于复杂,清晰优于机巧,安全优于不安全。

       要避免使用程序设计语言中的冷僻特性。应该使用最简单的有效技术。不要使用不必要的操作符重载

       构造函数的参数,应该使用命名变量,而不要使用临时变量

       这能够避免可能的声明二义性,还经常能使代码的意图更加清晰,从而更容易维护,而且也更安全。

       第八条 编程中应该知道何时和如何考虑可伸缩性

       当数据爆炸性增长时:不要进行不成熟的优化,如果能够证明优化必要而且非常重要,则应该集中精力改善算法的复杂性,而不是进行小型的优化,比如节省一个多余的加法运算。

       为了避免未来可能遭遇到的数据处理容量上的瓶颈问题,应该预先做这些事情:

       使用灵活的、动态分配的数据,不要使用固定大小的数组

       那种“比现在所需要的最大数组还要大”的数组,在正确性和安全性方面都存在严重问题。只有在编译时大小固定不变的数组才是可接受的。

       了解算法的实际复杂性

       要留心那些不易发觉的陷阱,比如看似线性的算法实际上要调用其他线性操作,结果算法实际上是二次的。

       优先使用线性算法或者尽可能快的算法 尽可能避免劣于线性复杂性的算法

       如果面对的是一个O(NlogN)或者O(N²)算法,就必须花费精力寻找替代方案,只有代码才不至于在数据量显著增长的情况下陷入深度激增的性能深潭。例如:建议使用范围成员函数(通常是线性的)而不是反复调用单元素替代函数,后者会很容易在一个线性的操作要调用另一个线性操作时变成二次复杂性。永远不要使用指数复杂性的算法,除非真的别无选择

       在决定接受指数算法之前,必须尽力寻找替代方案,因为对于指数算法来说,即使是数据量的有限增加,也会使算法的性能急剧下降。

       总而言之,要尽可能优先使用线性(或者更好的)算法,尽可能合理的避免使用比线性算法差的多项式算法。竭尽全力避免使用指数算法。

       第九条 不要进行不成熟的优化

       我们将不成熟的优化定义为这样的行为:以性能为名,使设计或代码更加复杂,从而导致可读性更差,却没有经过验证的性能需求(比如实际的度量数据与目标的比较结果)作为正当理由,因此本质上对程序没有真正的好处。

       因此,默认时,不要把注意力集中在如何使代码更快上;首先关注的应该是使代码尽可能的清晰和易读。

       第十条 不要进行不必要的劣化

       所谓不成熟的劣化一词,指的就是编写如下这些没有必要的、可能比较低效的程序:

       在可以用通过引用传递的时候,却定义了通过值传递的参数 在使用前缀 操作符很合适的场合,却使用后缀版本 在构造函数中使用赋值操作而不是初始化列表

       第十一条 尽量减少全局和共享数据

       共享会导致冲突:避免共享数据,尤其是全局数据。共享数据会增加耦合度,从而降低可维护性,通常还会降低性能。

       名字空间作用域中的对象、静态成员对象或者跨线程或跨进程共享的对象会减少多线程和多处理器环境中的并行性,往往是产生性能和可伸缩性瓶颈的源头。建议用通信方式(比如消息队列)代替数据共享。尽量降低类之间的耦合,尽量减少交互

       第十二条 隐藏信息

       不要泄密:不要公开提供抽象的实体的内部信息。而应该公开抽象(至少是get/set抽象),而不是数据。

       数据只是抽象、概念性状态的一种可能的具体化而已。如果将注意力集中在概念而不是其表示形式上,就能够提供富于提示性的接口,并按需要对实现进行调整。比如缓存还是实时地计算,又比如使用不同的表示方式,针对某种使用模式进行优化。

       绝对不要将类的数据成员设为public,仅对最需要的类型标记为public,其他的标记为internal。它同样适用于更大的实体比如程序库。模块和程序库同样应该提供定义抽象和其中信息流的接口,从而使与调用代码的通信比采用数据共享方式更安全,耦合度更低。

       第十三条 尽量在编译和连接时检查错误,而不要等到运行时

       运行时检查取决于控制流和数据的具体情况,这意味着很难知道检查是否彻底。相比而言,编译时检查与控制流和数据无关,一般情况下能够获得更高的可信度。

       第十四条 尽量合理的使用const常量

       不变的值更易于理解、跟踪和分析,所以应该尽可能地使用常量代替变量,定义值的时候,应该把常量作为默认的选项:常量很安全,在编译时会对其进行检查。尽量不要强制转换常量的类型。

       例如:

       const int x = 0;public const double productWeight = 11.7;private const string productName = “Visual C#”;

       第十五条 避免使用语义不清的参数

       要避免在代码中使用诸如42和3.14159这样的文字常量。它们本身没有提供任何说明,并且因为增加了检测的重复而使维护更加复杂。可以用符号名称和表达式替换它们,比如width*aspectRatio

       名称能够增加信息,并提供单一的维护点,而程序中到处重复的原始数据是无名的,维护起来很麻烦。常量应该是枚举或者const值,有合适的作用域和名称。

       重要的特定于领域的常量应该放在名字空间一级

       第十六条 尽可能局部的使用变量 第十七条 避免函数过长,避免嵌套过深

       过长的函数和嵌套过深的代码块的出现,经常是因为没能赋予一个函数以一个紧凑的职责所致,这两种情况通常都能够通过更好的重构予以解决。每个函数都应该是顾其名而能思其义,易于理解的工作单元,要避免将多个小概念单元合并到一个长的函数体中的做法。

       一些建议:

       尽量紧凑:对一个函数只赋予一种职责

       不要自我重复:优先使用命名函数,而不要让相似的代码片断反复出现 优先使用&&:在可以使用&&条件判断的地方要避免使用连续嵌套的if 不要过分使用try 优先使用标准算法

       不要根据类型标签(type tag)进行分支(switch)第十八条 尽量减少定义性依赖,避免循环依赖

       循环依赖是指两个模块直接或者间接地相互依赖。所谓模块就是一个紧凑的发布单元,而互相依赖的多个模块并不是真正的独立模块,而是紧紧胶着在一起的一个更大的模块,因此,循环依赖有碍于模块性,是大型项目的祸根。请避免循环依赖。

       第十九条 不要引用多余的资源文件 第二十条 尽量不要重载默认的操作符,至少应保证操作符的自然语义不被破坏 第二十一条 优先使用 和—的标准形式。优先调用前缀形式。第二十二条 用小类代替巨类

       小类更易于编写,更易于保证正确、测试和使用。小类更有可能适用于各种不同情况。应该用这种小类体现简单概念,不要用大杂烩式的类。

       第二十三条 要避免使用隐式转换

       在做类型提供隐式转换之前,请三思而行,应该依赖的是显式转换。

       隐式转换有两个主要的问题:

       1.它们会在最意料不到的地方抛出异常

       2.它们并不总是能与语言的其他元素有效地配合 第二十四条 将数据成员设为私有的,无行为的聚集

       要避免将公用数据和非公用数据混合在一起,因为这几乎总是设计混乱的标志。信息隐藏是优秀软件工程的关键,应该将所有数据成员都设为私有的,这是类用来保持其不变式的最佳方式。

       第二十五条 不要允许异常跨越模块边界传播

       最低限度,应用程序必须在以下位置有捕获所有异常的catch(…)兜底语句,其中大多数都直接适用于模块:

       1.在main函数的附近:捕获并用日志记录任何将使程序不正常终止而其他地方又没有捕获的异常。

       2.在从无法控制的代码中执行回调附近3.在现场边界的附近4.在模块接口边界的附近

       5.在IO,数据库连接等高危操作附近

       第二十六条 如有可能,尽量用算法调用代替手工编写的循环

       对非常简单的循环而言,手工编写的循环有可能是最简单也是最有效的解决方案。但是编写算法调用代替手工编写的循环,可以使表达力更强、维护性更好、更不易出错,而且同样高效。

       第二十七条 编码惯例

       1. 避免在一个文件中放多个类

       2. 一个文件应该只对一个命名空间提供类型,避免在同一文件中有多个命名空间 3. 避免一个文件的长度超过500行(除了机器生成的代码)4. 避免方法定义超过25行

       5. 避免超过5个参数的方法,使用结构传递多个参数 6. 每行应该不超过80个字符,或者10个单词 7. 不要手工编辑任何机器生成的代码

       A.如果修改机器生成的代码,修改代码格式和风格以符合本编码标准 B.尽可能使用partial类以分解出需要维护的部分 8. 避免对显而易见的内容作解释

       A.代码应该是自解释的,由可读性强的变量和方法组成的好的代码应该不需要解释 B.参加第一条中的解释部分

       9. 仅对操作的前提、内在的算法等写文档 10. 避免方法级的文档

       A.对API文档采用大量的外部文档

       B.方法级解释仅作为对其他开发人员的提示 11. 决不要硬编码数值,声明一个常量是最好的选择 12. 仅对本轮就是常量的值使用const修饰符,例如一周的天数 13. 避免对只读变量使用const修饰符。在此情况下,采用readonly修饰符

       public class MyClass { public const int DaysInWeek = 7;public readonly int Number;public MyClass(int someValue){ Number = someValue;} }

       14.对任何假设采用assert。平均来讲,每五行代码中就有一行是断言

       using System.Diagnostics;object GetObject(){} object someObject = GetObject();Debug.Assert(someObject!= null);

       15. 16. 17. 每行代码都应该经过白盒测试 仅捕获已经显式处理了的异常

       在抛出异常的catch语句中,总是抛出最初异常以保持最初错误的堆栈位置

       catch(Exception exception){ MessageBox.Show(exception.Message);throw;}

       18. 定义自定义的异常时

       A.从ApplicationException继承 B.提供自定义的序列化 19. 避免采用friend程序集,因为这样增加了程序集间的耦合度 20. 避免使用依赖于从特定位置运行的程序集的代码。21. 尽量减少应用程序集(客户端EXE程序集)的代码,采用类库而不要包含业务逻辑层代码。22. 避免对枚举提供明确的值

       //正确

       public enum Color { Red,Green,Blue } //错误

       public enum Color { Red=1,Green=2,Blue=3 }

       23. 避免对枚举指定类型

       //错误

       public enum Color : long { Red, Green, Blue }

       24. 25. 26. If语句总是使用括号,即使它只包含一句语句 避免使用?:条件运算符 避免使用(#if…#endif),应使用conditional方法代替

       [Conditianal(“MySpecialCondition”] public void MyMethod(){}

       27. 避免在布尔条件语句中调用函数,赋值到局部变量并检查它们的值。

       bool IsEverythingOK(){} //错误

       if(IsEverythingOK()){} //正确

       bool ok=IsEverythingOK();if(ok){}

       28.29. 总是使用从0开始的数组

       总是使用一个for循环显式地初始化一个引用类型数组

       public class MyClass {} const int ArraySize=100;MyClass[] array=new MyClass{ArraySize];for(int index=0;index

       30. 31. 不用提供public或protected成员变量,而是使用属性 应尽量使用get/set的自动返回属性

       //错误

       class MyClass { int m_Number;

       public int Number { get { return m_Number;} set { m_Number=value;} } } //正确

       class MyClass { public int Number { get;set;} }

       32. 33. 34. 35. 避免使用new,应使用override替代

       在一个密封的类里总是把public和protected方法标记为virtual 永远不要使用不安全的代码 合理使用as操作符进行映射

       Dog dog = new GermanShepherd();GermanSheperd shepherd = dog as GermanShepherd;if(shepherd!= null){} 36. 37.

       { 在使用一个委托前总是要先检查它是否为空(null)

       不要提供公有成员变量,使用存取器(accessors)进行替代

       public class MyPublisher MyDelegate m_SomeEvent;public event MyDelegate SomeEvent { add { m_SomeEvent = value;} remove { m_SomeEvent-= value;} } }

       38. 避免定义事件处理委托,使用EventHandler或者GenericEventHandler进行替代 39. 使用EventsHelper安全的发布事件 40. 总是优先使用接口,但要避免一个接口只包含一个成员,包含3-5个成员较为合适。上限为12。41. 避免事件成为接口成员 42. 提供明确定义的接口描述 43. 不要假设一个接口是可以安全运作的,永远都要做好处理意外的准备

       SomeType obj1;IMyInterface obj2;

       obj2=obj1 as IMyInterface;if(obj2!= null){ obj2.Method1();} else { //处理可能出现的错误

       }

       44. 不要将可能改变的,或用于数据库连接的,或者交付给最终客户使用的任何字符串进行硬编码,要使用资源文件定义他们 45. 使用String.Empty代替””

       //错误

       string name = “";//正确

       string name = String.Empty;

       46. 47. 48.

       定义长字符串的时候,应该使用StringBuilder,而不是string 永远不要使用goto语句,除非迫不得已

       在switch代码块中总要包含一个default项,并且为其设置断言

       int number = SomeMethod();switch(number){ case 1: Trace.WriteLine(”Case 1:“);break;case 2: Trace.WriteLine(”Case 2:“);break;default: Debug.Assert(false);break;}

       49.不要使用this引用,除非某些特殊情况,比如从一个构造器中运行另外一个

       //一个正确使用this的例子

       public class MyClass { public MyClass(string message){} public MyClass():this(”Hello"){} }

       50. 不要使用base关键词。除非你想要解决一个子类成员和基类间的名称冲突,或者运行一个基类构造器

       //一个正确使用base的例子

       public class Dog { public Dog(string name){} virtual public void Bark(int howLong){} } public class GermanShepherd:Dog { public GermanShepherd(string name):base(name){} public override void Bark(int howLong){ base.Bark(howLong);} }

       51. 不要使用GC.AddMemortyPressure(),不要依赖HandleCollector。合理的使用Dispose()和Finalize()方法 52. 一般情况下不要使用check来检查代码(防止性能损失),但是在可能的溢出区则使用check来保持代码的安全性。安全性的优先级永远高于性能。

       int CalcPower(int number,int power){ int result=1;for(int count=1;count<=power;count ){ checked { result*=number;} } return result;}

       53. 在代码中要避免直接使用object数据类型(System.Object),可以使用约束或者as进行替代。

       class SomeClass {} //错误

       class MyClass { void SomeMethod(T t){ object temp=t;SomeClass obj=(SomeClass)temp;} } //正确

       class MyClass where T: SomeClass { void SomeMethod(T t){ SomeClass obj =t;} }

       54.{} 一般而言,不要在通用接口中定义约束。接口级别的约束经常会被强类型所覆盖

       public class Customer //错误

       public interface IList where T: Customer {} //正确

       public interface ICustomerList:IList {} 第二十八条 安全

       1. 总是对应用程序私有的组件,集合等使用强名,这样可以保证安全性

       2. 在应用程序配置文件中使用加密算法,进行安全保护

       3. 对不受控制的引用方法,要做适当的安全处理,如加入断言控制

       4. 不要使用SuppressUnmanagedCodeSecurity属性 5. 不要使用/unsafe来切换TlbImp.exe的默认行为。

       6. 在服务器端要使用自定义的安全规则来扩展Microsoft的默认配置,以保证更高级别的安全性

       7. 为防止引诱性攻击,应修改组件级别的运行权限,限制其可能的不安全行为

       8. 在编写Windows程序时,在每个Main()中都要使用相应的安全规则

第三篇:参考文献及解释规范

       一、基本概念

       (1)“解释”指进一步解释自己所要表达的意思,解释安排在当页页脚,用带圈数字表示序号,如注①、注②等,解释的序号与文中序号一一对应。

       (2)“参考文献”指引文所注的出处,一律放在论文尾末,文中设序号 [1],参考文献的序号与文中序号一一对应。页码置于文中序号之后,例: [1](P12)。

       (3)“参考文献”也指虽未直接引述别人的话、但参考了别人著作和论文的意思,应在段中或段末设序号 [1],并在文末注明。本项与第2项不必分列,交叉排序即可。文末的序号与文中序号一一对应。此种情况可以不注明页码。

       (4)同一参考文献多次被引用,文末只标一个序号,文中应多次出现同一序号,在文中序号后加圆括号,注明所引文献的不同页码或篇名。

       (5)参考文献与解释的区别。参考文献是写作论著时所参考的文献书目,集中列于文末;解释则是对论著正文中某一特定内容的进一步解释或补充说明,列于该页地脚(以脚注形式标出)。参考文献序号用方括号标注,解释序号则用数字加圆圈标注,位于标点符号之后;若是直接引文,则位于后引号之后。

       二、中文参考文献及解释规范

       (一)、文后参考文献及其随文夹注格式

       参考文献按在正文中出现的先后次序列于文末,以“参考文献:”(左顶格)作为标识。参考文献的序号左顶格,并用数字加方括号表示,如[1],[2],…;每一条参考文献条目的最后均以小圆点“.”结束。

       引文的起止页码以随文以夹注的形式、用6号宋体标出,其格式为:[序号](p×)。各类参考文献及其在正文中夹注的格式及示例如下:

       1、专著、论文集、学位论文、报告

       [序号]主要责任者.文献题名[文献类型标识].出版地:出版者,出版年.[1] 列维·布留尔.原始思维[M].北京:商务印书馆,1987.[2] 马克思.恩格斯.共产党宣言[A].马克思恩格斯选集[M].第一卷.北京:人民出版社,1972.[3] 洪亮吉.春秋左传诂[M].卷三.[4] 人事部一·叙人[A].太平御览[M].北京:中华书局,1960.[5] 皇甫湜.皇甫持正文集[M].卷四.四部丛刊本.[6] 房玄龄等.晋书·司马彪传[M].北京:中华书局,1974.[7] Chester.The Rise of British Industrial Society[M].Longman, 1982.以例[6]、[7]为例,其随文夹注格式分别为: [6](p.4142.)、[7](p.289.)。

       多次引用同一本书中的材料,随文夹注中一律采用第一次出现的序号。例如:第一次引用[7]中材料时,夹注为“[7](p289)”;第二次引用[7]中材料时,夹注为“[7](p163)”。多种材料说明一个问题,在随文夹注中则按次序列出,例:“[4](p×);[5](p×)”。

       2、期刊文章

       [序号]主要责任者.文献题名[J].刊名,年,卷(期).例:

       [8] 李醒民.哲学不是敲门砖和摇钱树[J].学术界,2000,(1).随文夹注格式: [8](p206)。

       3、论文集中的析出文献

       [序号]析出文献主要责任者.析出文献题名[A].原文献主要责任者(任选).原文献题名[C].出版地:出版者,出版年.例:

       [9] 王旭.美国三大城市与美国现代区域经济结构[A].中国美国史研究学会.美国现代化历史经验[C].北京:东方出版社,1994.随文夹注格式:[9](p183)。

       4、报纸文章

       [序号]主要责任者.文献题名[N].报纸名,出版日期(版次).例:

       [10]杨玉圣.把书评当作学问来做[N].中华读书报,1996-10-09(2).5、电子文献

       [序号]主要责任者.电子文献题名[电子文献及载体类型标识].电子文献的出处或可获得地址,发表或更新日期/引用日期.例:

       [11]王明亮.关于中国学术期刊标准化数据库系统工程的进展[EB/CD].http://,1998-08-16/1998-10-04.报纸文章和电子文献在随文夹注中直接以序号标出,而省略“(p×)”著录项。

       6、各种未定义类型的文献 [序号]主要责任者.文献题名[Z].出版地:出版者,出版年.例:

       [12]何晓明.降落民间——21世纪中国历史学走向管窥(第十一届全国史学理论研讨会论文)[Z].武汉:湖北大学中国文化研究院,2000.三、英文参考文献及解释规范

       英文参考文献Bibliography(Bibliography使用“Times New Roman”字体,小四号,加粗,后面不加任何标点符号。)

       1.专著:

       1)基本格式(请严格注意标点符号):的姓名(英文的姓,名).年份.书名(斜体).出版地:出版商.如果同一两本以上同年出版的参考书,在年份后用a,b,c 等标出; 如有第二行,则须缩进4个英文字符。例:

       Chomsky, N.1981a.Lectures on government and binding.Dordrecht: Foris.Chomsky, N.1981b.Theory of markedness in generative grammar.Pisa, Italy: Scuola Normale Superiore.2)书的主编(格式:各项信息的排列顺序基本同上,在主编姓名后加ed.):

       例:Hall, David, ed.1981.The Oxford book of American literary anecdotes.New York: OUP.3)机构(格式:各项信息的排列顺序基本同上):

       例:American library association.1983.Intellectual freedom manual.2nd ed.Chicago: ALA.4)翻译著作(格式:各项信息的排列顺序基本同上,加xx Trans.):

       例:Calvino, Ian.1986.The uses of literature.P.Creagh Trans.San Diego: Harcourt.2.文章:

       1)期刊文章基本格式(请严格注意标点符号):姓名.年份.篇名.刊名(要斜体).刊物的卷号和期号:文章的起止页码.例:

       Boling, D.1965.The atomization of meaning.Language 41:555-573.2)论文集中的文章基本格式(请严格注意标点符号):姓名.年份.篇名.论文集姓名.eds.论文集名称(要斜体).出版地:出版商.文章的起止页码.例:

       Peters, M & T.B.Stephen.1986.Interaction routines as cultural influences upon language acquisition.In Schieffelin, B.B.& E.Ochs, eds.Language Socialization Across Cultures.Cambridge: CUP, 80-96.附1:参考文献类型及其标识

       参考文献 专著 论文集 析出文献 报纸文章 期刊文章 学位论文 报告

       文献类型标识 M C A N J D R 无法根据上述分类的文献,其标识码一律用“Z”表示。

       附2:电子文献的载体类型及其标识([文献类型标识/载体类型标识])

       电子文献载体类型:磁带(magnetic tape)——MT;磁盘(disk)——DK;光盘(CD-ROM)——CD;联机网络(online)——OL。按下列格式表示包括了文献载体类型的参考文献类型标识:

       [DB/OL]——联机网上数据库(database online)

       [DB/MT]——磁带数据库(database on magnetic tape)

       [M/CD]——光盘图书(monograph on CD-ROM)

       [CP/DK]——磁盘软件(computer program on disk)

       [J/OL]——网上期刊(serial online)

       [EB/OL]——网上电子公告(electronic bulletin online)

第四篇:学术论文解释规范

       解释的格式

       (一)中文解释:

       1、当文章引用或借用的资料所在的著作第一次出现于解释中时,须将该书姓名、书名、出版地、出版者、出版年代及引用资料所在的页码一并注出。

       (1)引

       用专著例:

       李道揆:《美国政府和美国政治》,北京.中国社会科学出版社,1990年版,第72-74页。

       说明:(a)姓名后面用冒号;著作名用书名号标出,书名号后加逗号;出版地后用间隔号(中圆点);出版社名称后加逗号;出版年代后加“版”字,再加逗号;页码后用句号。(b)著如系二人,姓名之间用顿号分隔,如:xxx、xxx;如系二人以上,可写出第一姓名,后面加“等”字省略其他,如:xxx等。(c)著作名如有副标题,则在书名号内以破折号将标题与副标题隔开。

       如:

       陈宝森:《美国经济与政府政策——从罗斯福到里根》,北京.世界知识出版社,1988年版,第124页。(d)著作如系多卷本,须在书名号后面直接写出引用资料所在的卷数,再加句号。如:徐民:《抗美援朝的历史回顾》上卷,北京.中国广播出版社,1990年版,第5页。(e)出版地应包括省、自治区及其下属的市名,直辖市只注市名,如:

       吉林延吉.延边教育出版社;北京.国际文化出版公司。如出版社名称本身已含其中某一级地名,则可不必在出版地中重复注出,如:南京.江苏人民出版社,不必注为江苏南京.江苏人民出版社;北京出版社,不必注为北京.北京出版社。

       (2)引用译著例:

       J.布卢姆等:《美国的历程》下册第二分册(杨国标、张儒林译,黄席群校),北京.商务印书馆,1988年版,第97页。

       说明:(a)姓名中除姓(family name)外,名与中间名(first name 和 middle name)均可用缩写形式表示,如缩写,须用英文缩写符号(下圆点);如将姓名全部译出,则须在姓名之间加中文间隔符号(中圆点)。(b)书名号后或多卷本著作卷次、册次后直接加圆括号,括号内注明中文译、校者姓名。

       (3)引用编著例:

       杨生茂主编:《美国外交政策史,1775—1989》,北京.人民出版社,1991年版,第23页。

       韩铁等:《战后美国史,1945—1986》(刘绪贻、杨生茂主编),北京.人民出版社,1989年版,第56页。

       说明:(a)第一例适用于仅有编者的著作。在编者姓名后,根据该书提供的信息加入“编”或“主编”,再加冒号;其余部分与著作类解释格式同。(b)第二例适用于既有编者,又有著者的著作。这类解释与著作类解释基本相同,但须在书名号后加圆括号,括号内注明编者姓名,再在括号后加句号。

       (4)引用文集或期刊、杂志内文章例:

       马克思:《哥达纲领批判》,载《马克思恩格斯选集》第三卷,北京.人民出版社,1972年版,第21页。

       弗.杰姆逊:《处于跨国资本主义时代中的第三世界文学》,载《新历史主义与文学批评》(张京媛主编),北京大学出版社,1992年版,第251页。

       吴展:《试论核裁军的几个问题》,载《美国研究》1994年第3期,第43页。

       说明:(a)先注名和篇名,篇名用书名号标出,书名号后加逗号;再注出文集或期刊名,文集或期刊名亦用书名号标出,书名号前加“载”字,紧接文集或期刊书名号后注明卷次、册次,然后加逗号;其余与著作类格式同。(b)第一例适用于编者未署名的文集;第二例适用于编者署名的文集。(c)期刊、杂志不必注明编者和出版者。(5)引用报纸文章例:

       陆全武:《国营企业改革中的几个问题》,1994年8月20日《经济日报》,第3版。

       《墨西哥股票市场动荡》,1995年1月10日《人民日报》,第7版。

       说明:(a)第一例适用于署名文章。(b)第二例适用于不署名文章或报道。(c)报纸出版时间须注明年、月、日,并置于报纸名称前。(d)报纸不注“页”,而注“版”。

       2、当再次引用同一著作中的资料时,解释中只需注出姓名、著作名(副标题可省略)和资料所在的页码;如引文出自报刊文章,报刊名称及出版日期则可以“上引报刊”四字代替。

       例:李道揆:《美国政府和美国政治》,第79页。

       J.布卢姆:《美国的历程》下册第一分册,第140页。

       陈宝森:《美国经济与政府政策》,第435页。

       吴展:《试论核裁军的几个问题》,上引报刊,第44页。

       《墨西哥股票市场动荡》,上引报刊,第7版。

       (二)英文解释:

       1、当首次引用一本著作的资料时,解释中须将该书的姓名、书名、出版地、出版者、出版年代及资料所在页码顺序注明。具体格式如下:

       (1)专著类:

       Harold U.Faulkner, American Economic History(New York: Harper & Brothers Publishers, 1960), pp.23-25.说明:(a)姓名按通常顺序排列,后面加逗号;书名用斜体,手稿中可在书名下用横线标出;书名后紧接圆括号,括号内注出版地,加冒号,后接出版者名称,再加逗号,然后注出版年代;括号后面加逗号,再注出引用资料所在的页码,页码后加句号表示解释完毕;单页页码用 p.表示;多页页码用pp.表示,意为pages。(b)如系二人,姓名之间用and或& 连接;如系二人以上,可写出第一姓名,后面加et al.表示and others,如:Donna Worrall Brown et al., Form in Modern English,其余与(a)同。(c)著作名如有副标题,则以冒号将其与标题隔开,如:Robert K.Murray, The Harding Era: Warren G.Harding and His Administration(Minneapolis: University of Minnesota Press, 1969), p.91.(d)著作如系多卷本中的一卷,须在注明页码前,用Vol.加罗马数字标明卷数,如:Ralph F.de Bedts, Recent American History: 1945 to the Present,Vol.II(Illinois: Dorsey Press, 1973), p.169.(2)编著类:

       Paul M.Angle, ed., The American Reader: From ColumbustoToday(New York: Rand McNally Co.,1958), pp.52-53.说明:(a)如编者系多人,则须将ed.写成eds.,如:E.B.White & Katherine S.White, eds.,A Subtreasury of American Humor,后面的解释内容与著作类同。(b)既有编者又有著者的著作,须将著者姓名置于书名前,编者姓名置于书名后,如:George Soule, Prosperity Decade: From War to Depression, 1917-1929(eds.Henry David et al., New York: M.E.Sharpe, Inc., 1975), p.235.亦可不注编者,按著作类解释处理。

       (3)文集内文章:

       Erwin Panofsky, “Style and Medium in the Motion Picture,” Problems in Aesthelics, ed.Morris Weitz(New York: Harcourt, Brace and World, Inc., 1969), p.326.说明:(a)文章名不用斜体或划线,与其后的逗号均置于引号内。(b)书名采用斜体,后面注出编者姓名,格式与编著类(b)相同。

       (4)报刊文章类:

       Constance M.Drake, “An Approach to Blake,” College English, XXIX(April 1968), pp.541-543.“Reading Teachers Put on Spot,” The Kansas City Star, May 1, 1969, p.16 A.说明:(a)第一例为引用期刊中署名文章的解释,期刊名称用斜体,卷号须用罗马数字标明,然后在圆括号内注出版日期;不必注编者、出版者和出版地。(b)第二例为引用报纸中不署名文章的解释,报纸名称用斜体,后面注出版日期。

       (5)电子信息类:

       如使用因特网上的资料,须注明资料所在站点详细地址:如http://,1998-08-16/1998-10-04.报纸文章和电子文献在随文夹注中直接以序号标出,而省略“(p×)”著录项。

       (六)各种未定义类型的文献

       [序号]主要责任者.文献题名[Z].出版地:出版者,出版年.例:

       [12]何晓明.降落民间——21世纪中国历史学走向管窥(第十一届全国史学理论研讨会论文)[Z].武汉:湖北大学中国文化研究院,2000.二、参考文献与解释的区别

       参考文献是写作论著时所参考的文献书目,集中列于文末;解释则是对论著正文中某一特定内容的进一步解释或补充说明,列于该页地脚(以脚注形式标出)。参考文献序号用方括号标注,解释序号则用数字加圆圈标注,位于标点符号之后;若是直接引文,则位于后引号之后。

       附1:参考文献类型及其标识

       参考文献 专著 论文集 析出文献 报纸文章 期刊文章 学位论文 报 告

       文献类型标识 M C A N J D R 无法根据上述分类的文献,其标识码一律用“Z”表示。

       附2:电子文献的载体类型及其标识([文献类型标识/载体类型标识])

       电子文献载体类型:磁带(magnetic tape)——MT;磁盘(disk)——DK;光盘(CD-ROM)——CD;联机网络(online)——OL。按下列格式表示包括了文献载体类型的参考文献类型标识:

       [DB/OL]——联机网上数据库(database online)

       [DB/MT]——磁带数据库(database on magnetic tape)

       [M/CD]——光盘图书(monograph on CD-ROM)

       [CP/DK]——磁盘软件(computer program on disk)

       [J/OL]——网上期刊(serial online)

       [EB/OL]——网上电子公告(electronic bulletin online)

第五篇:学术论文解释规范

       学术论文解释规范

       一、文后参考文献及其随文夹注格式

       参考文献按在正文中出现的先后次序列于文末,以“参考文献:”(左顶格)作为标识。参考文献的序号左顶格,并用数字加方括号表示,如[1],[2],…;每一条参考文献条目的最后均以小圆点“.”结束。

       引文的起止页码以随文以夹注的形式、用6号宋体标出,其格式为:[序号](p×)。

       各类参考文献及其在正文中夹注的格式及示例如下:

       (一)专著、论文集、学位论文、报告

       [序号]主要责任者.文献题名[文献类型标识].出版地:出版者,出版年.[1] 列维·布留尔.原始思维[M].北京:商务印书馆,1987.[2] 马克思.恩格斯.共产党宣言[A].马克思恩格斯选集[M].第一卷.北京:人民出版社,1972.[3] 洪亮吉.春秋左传诂[M].卷三.[4] 人事部一·叙人[A].太平御览[M].北京:中华书局,1960.[5] 皇甫湜.皇甫持正文集[M].卷四.四部丛刊本.[6] 房玄龄等.晋书·司马彪传[M].北京:中华书局,1974.[7] Chester.The Rise of British Industrial Society[M].Longman, 1982.以例[6]、[7]为例,其随文夹注格式分别为: [6](p.4142.)、[7](p.289.)。

       多次引用同一本书中的材料,随文夹注中一律采用第一次出现的序号。例如:第一次引用[7]中材料时,夹注为“[7](p289)”;第二次引用[7]中材料时,夹注为“[7](p163)”。多种材料说明一个问题,在随文夹注中则按次序列出,例:“[4](p×);[5](p×)”。

       (二)期刊文章

       [序号]主要责任者.文献题名[J].刊名,年,卷(期).例:

       [8] 李醒民.哲学不是敲门砖和摇钱树[J].学术界,2000,(1).随文夹注格式: [8](p206)。

       (三)论文集中的析出文献

       [序号]析出文献主要责任者.析出文献题名[A].原文献主要责任者(任选).原文献题名[C].出版地:出版者,出版年.例:

       [9] 王旭.美国三大城市与美国现代区域经济结构[A].中国美国史研究学会.美国现代化历史经验[C].北京:东方出版社,1994.随文夹注格式:[9](p183)。

       (四)报纸文章

       [序号]主要责任者.文献题名[N].报纸名,出版日期(版次).例:

       [10]杨玉圣.把书评当作学问来做[N].中华读书报,1996-10-09(2).(五)电子文献

       [序号]主要责任者.电子文献题名[电子文献及载体类型标识].电子文献的出处或可获得地址,发表或更新日期/引用日期.例:

       [11]王明亮.关于中国学术期刊标准化数据库系统工程的进展[EB/CD].http://,1998-08-16/1998-10-04.报纸文章和电子文献在随文夹注中直接以序号标出,而省略“(p×)”著录项。

       (六)各种未定义类型的文献

       [序号]主要责任者.文献题名[Z].出版地:出版者,出版年.例:

       [12]何晓明.降落民间——21世纪中国历史学走向管窥(第十一届全国史学理论研讨会论文)[Z].武汉:湖北大学中国文化研究院,2000.二、参考文献与解释的区别

       参考文献是写作论著时所参考的文献书目,集中列于文末;解释则是对论著正文中某一特定内容的进一步解释或补充说明,列于该页地脚(以脚注形式标出)。参考文献序号用方括号标注,解释序号则用数字加圆圈标注,位于标点符号之后;若是直接引文,则位于后引号之后。

       附1:参考文献类型及其标识

       参考文献 专著 论文集 析出文献 报纸文章 期刊文章 学位论文 报 告

       文献类型标识 M C A N J D R 无法根据上述分类的文献,其标识码一律用“Z”表示。

       附2:电子文献的载体类型及其标识([文献类型标识/载体类型标识])

       电子文献载体类型:磁带(magnetic tape)——MT;磁盘(disk)——DK;光盘(CD-ROM)——CD;联机网络(online)——OL。按下列格式表示包括了文献载体类型的参考文献类型标识:

       [DB/OL]——联机网上数据库(database online)

       [DB/MT]——磁带数据库(database on magnetic tape)

       [M/CD]——光盘图书(monograph on CD-ROM)

       [CP/DK]——磁盘软件(computer program on disk)

       [J/OL]——网上期刊(serial online)

       [EB/OL]——网上电子公告(electronic bulletin online)