PO_ABAPCoding规范(模板)
SAP-ABAP 程序规范
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
语句规范
MODIFY
MODIFY IT_TAB FROM WA_TAB INDEX SY-TABIX TRANSPORTING COL1 COL2 WHERE KEY1 = XXX AND KEY2 = XXX
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
语句规范
READ
例: CLEAR WA_TAB. READ TABLE IT_TAB INTO WA_TAB WITH KEY COL1 = XXX COL2 = XXX IF SY-SUBRC = 0. ELSE. ENDIF.
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
SAP-ABAP 培训 --程序规范
ABAP 程序规范
程序模板 语句规范 编程规范 程序相关文档
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
程序模板
E:\work\IBM\ TEMPLATE_DEVt Information Systems Co.,Ltd. 柯莱特信息系统有限公司
Camelot Information Systems Co.,Ltd. 柯莱特信息系统有限公司
ABAP开发功能规格说明书模板
此处的签名，表示企业的负责用户确认本文档内容中的报表需求及功能设计。
姓名：……………………………………
职务：……………………………………
日期：……../……../……..
文件名: : 日期: 5/8/2013
关键用户签名
姓名：……………………………………
日期：……../……../……..
业务顾问签名
姓名：……………………………………
日期：……../……../……..
文件名: : 日期: 5/8/2013
报表用途（描述编写报表的用途或目的）
总体要求（报表/程序执行的功能描述）
报表使用者
使用频度（日、月、季度或年）
后台处理/在线处理
打印机类型（激光 / 喷墨 / 针式）
纸张大小/方向
使用语言
开发优先度
注释
文件名: : 日期: 5/8/2013
5.1权限要求（对于某些个别字段须要进行权限控制，如公司代码等）
5.3所需数据表及字段描述
5.5报表 / 表单的输出格式及备注
（附报表格式）
文件名: : 日期: 5/8/2013
文件名: : 日期: 5/8/2013。
ABAP Report一般格式
*&----------------------------------------------------------------------
*AT SELECTION-SCREEN.
*
*Extras:
*******************************(3)列表事件Begin******************************
*处理一此报表的交互,如普通列表、ALV等*
*&---------------------------------------------------------------------*
* Date Programmer Correction Number Correction Type *
* Descriptions:
* 2.1 <功能简介>
* 2.2 <功能前提>
************************************************************************
*& TABLES:
*&---------------------------------------------------------------------*
*TABLES: ZTEST
*&---------------------------------------------------------------------*
* END-OF-SELECTION 选择结束事件,一般用于输出列表
*----------------------------------------------------------------------*
SAP_ABAP开发标准书2
ABAP开发标准书序言<目的>该文档定义了在开发与维护ABAP程序过程中必须遵守的规范与标准。
该文档应当被视为一个动态的文档，该文档会根据需要进行增补和修订。
开发规范的重要作用在于保持整个开发团队的开发风格一致，提高程序质量，降低维护压力。
<对象范围>ABAP Developer(如：创建或维护ABAP程序、ABAP Dictionary 对象)必须遵守该文档中的规范约束。
ABAP (1)开发标准书 (1)1 开发规范介绍 (8)2 程序属性 (10)3 程序命名规则 (11)3.1方针 (11)3.1.1 对象名称 (11)3.2 基本命名基准 (11)3.2.1 用户开发的开头文字 (11)3.2.2 系统简称 (11)3.2.3 Module简称 (12)3.2.4 表示处理功能的英文字 (12)3.3.1 Program (13)3.3.2Function Group (14)3.3.3 Function Module (14)3.3.3.1 Function Module名 (14)RFC的区分待整理 (14)3.3.3.2 Import Parameter (14)3.3.3.3 Export Parameter (14)3.3.3.4 Changing Parameter (14)3.3.3.5 Table Parameter (14)3.3.3.6 接口 (14)3.3.5 Set/Get Parameter (15)3.3.6 Dynpro Program (15)3.3.6.1 Dynpro 界面号 (15)3.3.6.2 Module Pool (16)3.3.6.3 Include Program (16)3.3.6.4 Dynpro画面部件 (17)3.3.7 Message (18)3.3.7.1 Message Class (18)3.3.7.2 Message ID (18)3.3.8 编号范围Object（SNRO） (18)3.3.9 Text Element (19)3.3.10 宏(Macro) (19)3.3.11功能代码 (19)3.4 ABAP Program Object (20)3.4.1 Table (20)3.4.1.1 主档表 (20)3.4.1.2 描述表 (20)3.4.2结构 (21)3.4.2.1 结构名 (21)3.4.2.2 构造项目名 (21)3.4.3 其他 (21)3.4.3.1 表类型 (21)3.4.3.2 视图（View） (21)3.4.3.3 Data Element (22)3.4.3.5 Lock Object (22)3.4.3.6 检索help (22)3.5 增强Object (22)3.5.1 Customer Exit (22)3.5.1.1 增强Object（CMOD） (22)标准的名称第一位换成Z (23)3.5.2 Table扩张 (23)3.5.2.1 Append構造 (23)3.5.3 BADI (23)3.5.3.1 命名 (23)3.5.3.2 Class 命名 (23)3.5.4BAPI (23)3.5.5 IDOC (23)3.5.5.1 Subporject (23)3.5.5.2Partner Type (24)3.5.5.3 Partner 号 (24)4 程序格式标准 (25)4.1 Pretty Printer (25)4.2 程序说明 (25)4.3 注释 (26)4.4程序修改 (26)4.4.1追加时 (26)4.4.2删除时 (26)4.4.3修改时 (27)5 ABAP语法 (28)5.1 TABLES参照构造定义 (28)5.2 TYPES定义 (28)5.3内表定义 (29)5.4 工作区定义 (29)5.5 固定值定义 (29)5.6 全局变量定义 (30)5.7 PARAMETERS & SELECT-OPTIONS (30)5.8 事件 (30)5.8.1INITIALIZATION事件 (30)5.8.2 AT SELECTION SCREEN事件 (31)5.8.3 事件记述方法 (31)5.9 FORM (33)5.9.1 FORM说明 (33)5.9.2 FORM抬头 (33)5.9.3 FORM内的变量 (34)6 命令相关 (35)6.1数据赋予 (35)6.2 处理块结束命令 (35)6.3 算术计算 (35)6.4 分支处理 (35)6.4.1逻辑运算符 (35)6.4.2多分支处理 (36)6.5 文字列操作 (36)6.5.1 文字列比较 (36)6.5.2 文字列结合 (36)6.5.3文字列分割 (36)6.5.4空格删除 (36)6.5.5项目值置换 (37)6.6数据库处理 (37)6.6.1更新 (37)6.6.2.2 件数计算 (37)6.6.2.3 单一数据取得 (38)6.6.2.4 集计函数 (38)6.6.2.5 记录的存在性检查 (38)6.6.2.6 内表保存 (39)6.6.2.7 项目取得 (39)6.6.2.8 重复数据的删除 (39)6.7 内表处理 (40)6.7.1 READ (40)6.7.2 LOOP (40)6.7.3 APPEND (40)6.7.4 SORT (41)6.7.5 重复数据删除 (41)6.8 数据转移 (41)6.8.1 相同构造的数据转移 (41)6.8.2 不同构造的数据转移 (41)1 开发规范介绍开发规范的应用能够提升系统运行生命周期中开发、测试、维护阶段的工作效率。
ASP编码规范书
产品编码规范书北京北大方正集团公司北京大学计算机科学技术研究所2001年03月一、语言选择服务器端脚本尽量使用JavaScript，原因在于VBScript的错误处理会影响代码的可读性.二、书写格式代码书写格式整齐统一、、层次清晰便于阅读。
●缩进TAB键统一为4个空格●赋值语句(=)及逻辑判断符(> < != && ||...etc)左右各空一格●算术运算符左右各空一格●if/while/switch之类的语句右边空一格●每个成员函数内部各个子功能之间用一个空行●公用成员放在程序的最前面，私用成员在后。
三、恰当地使用注释注释应简洁、清楚。
●不提倡使用/* 和*/来注释, 最好使用//来注释。
如果是对某一段程序(算法/结构)的注释, 在程序头直接用//再空一格来进行说明,一行不要超过80字符●注释就占程序的30%，如10行代码中就有不小于3行的注释。
四、关于命名1、变量必须显式定义如果使用VBScript,使用变量前必须显式定义。
虽然VBScript支持变量不定义就直接使用,但使用未经定义的变量可能会导致不可预知的错误。
可以在asp文件的所有执行代码前添加<% OPTION EXPLICIT %>强制要求变量定义.2、变量的命名除了循环变量i,j,k...之外，文件、类、(成员)变量、(成员)函数的命名要有意义，大小写相间，一目了然；成员变量、函数(Method)的首字母小写全局变量名称以“g_”开头。
3、匈牙利命名法命名时可以遵循匈牙利命名法它通过在数据和函数名中加入额外的信息以增进程序员对程序的理解。
如字符串,前面加上str;.var strTemp = “This is ……”；i -----> intu -----> UINTw -----> WORDdw -----> DWORDb -----> BOOLby -----> BYTEch -----> CHARsz -----> CHAR ARRAYstr-----> STRINGl -----> LONGf -----> floatd -----> doubleq -----> SINT64uq -----> UINT64v -----> voidfn -----> functionh -----> HANDLErect -----> RECT, CRectpt -----> POINT, Cpointo ---->objecttxt---->textboxchk---->checkboxrdo--→radiocbo---->select(dropdown)lst---->select(list)div---->DIVpwd---->passwordtbl---->tablefra--→frameconn--→ADODB.CONNECTIONrs--→ADODB.RECORDSET五、局部变量一定要初始化如果你声明一个变量，不要以为编译器会自动将之赋零值！你随手给它赋个初值并不麻烦，却会使程序更可靠，var fTemp = 0.0;六、.成员函数：成员函数的功能一定要单一；实现其功能时不要过分追求技巧，函数体不能过长七、.数组和缓冲区的使用对数组和缓冲区进行检查，防止越界，尤其是变长的情况下八、.尽量不要用goto语句特别谨慎使用goto语句，最好别用它尽管goto语句在某些特殊的情况下（比如编译器中）还很管用, 但它破坏了整个程序的结构，尤其使用goto嵌套时，更让人一头雾水(很久以前就有人提出取消它)。
SAP_ABAP_TCODE讲解
stad 可以查到6天内所有的日志DD01V 可以查询数据元素CMOD SAP增强DB15 表格和存档对象DB2 数据库状态OS01 可以查到当前连接的电脑名称OS03 操作系统的参数改变OS04 本的系统配置OS05 远程系统配置OS06 本地系统监视器OS07 远程系统监视器OSS1 登陆到OSSSE13 维护技术设置SM21 系统日志,本地分析SM02 系统消息SM01 事务代码系统管理SM28 安装检查SMLT 语言管理USMM 系统测量SARA 数据归档LICENSE_ADMIN 合并系统测量SM59 RFC目的地SM5E TXCOM维护SM55 THOST维持SICF HTTP服务层次结构维护SCC4 集团建立SCCL 本地集团复制SCC9 远程集团复制SCC1 复制传送请求SCC5 删除集团SCC3 复制日志SCC8 集团输出SCC7 输入编辑SCU0 跨系统查看器SCMP 对象比较SM50 进程概蓝SM51 服务器SM04 用户概蓝SMGW 网关接控器SMICM INTERNET 通讯管理员SM13 更新SM35 批输入SM58 事务性RFCST05 执行跟中ST01 系统轨迹ST11 开发者轨迹SSAA 系统管理助手SU56 用户缓冲区SM56 数字范围缓冲区SM12 锁定条目ST22 转储分析SM19 配置SM20 分析SM18 重新组织SU01 用户SU01D 显示用户SU10 用户批维护SUGR 维护用户组SUCOMP 公司地址file 设定论理路经AL11 查看服务器文件slg1 可以查到某用户的日志文件先写到这里.以后再写.login/system_client 650保存后，重启SAP服务就生效。
要限制同一个帐号同一时间只能在一台机器上登陆，不能同时在多台机器上使用，系统参数是什么？ login/disable_multi_gui_login1.增加参数rdisp/gui_auto_logout = 02.表USR41可以看到用户登陆时间的长度3.写个批处理,可以每次用这个来启动SAP服务startsap name=T01 nr=00 SAPHOST=jpzx014.rdisp/max_alt_modes 设置启动多少个画面。
abap报表编程模板
ABAP/4 报表编程模板*&--------------------------------------------------------------**& Report Z_X_XXXXX*& Module : Module \ SubModule*&--------------------------------------------------------------**& Created : author (2003.10.09)*& Modified : author (someday)* Intention : 程序的详细说明* 请用户在ABAP/4 REPORT编程时，参考本程序提供的编程框架** 在编码规范有出入时，以本程序为准* 以下各事件可根据实际编程需要使用，对于需要处理的事件，可将该事* 件后面的语句注释去掉，再编写相应的子程序代码。
*&--------------------------------------------------------------*INCLUDE Z_X_XXXXXTOP . " TOP 子程序，用来声明全局变量*----以下三个子程序只有在多个程序调用同一逻辑时才建议使用-----**INCLUDE Z_X_XXXXXO01 . " PBO 子程序*INCLUDE Z_X_XXXXXI01 . " PAI 子程序*INCLUDE Z_X_XXXXXF01 . " form 子程序INITIALIZATION.* PERform INI_SELECTION_SCREEN. " 初始化选择屏上的变量AT SELECTION-SCREEN.* PERform INI_DATA. " 初始化全局变量START-OF-SELECTION.* PERform PRECESS_DATA. " 主要数据处理逻辑AT LINE-SELECTION.* PERform PRECESS_LINE_SELECTED. " 行选择时的处理AT USER-COMMAND.* PERform PRECESS_USER_COMMAND. * 用自定义命令按钮时的处理TOP-OF-PAGE.* PERform PAGE_HEADER. " 页眉END-OF-PAGE.* PERform PAGE_FOOT. " 页脚*& form PRECESS_DATA*&--------------------------------------------------------------** text*---------------------------------------------------------------** --> p1 text* <-- p2 text*---------------------------------------------------------------*form PRECESS_DATA.*如果逻辑简单, 则合并若干form为一个PERform SEL_DBTAB_XXXXX. " 从透明表中取数据赋给内表 PERform CMP_ITAB_XXXXX. " 内表中数据计算处理PERform WRT_ITAB_RESULT. " 输出内表数据ENDform. " PRECESS_DA TA*&--------------------------------------------------------------**& form SEL_DBTAB_XXXXX*&--------------------------------------------------------------** text*---------------------------------------------------------------** --> p1 text* <-- p2 text*---------------------------------------------------------------*form SEL_DBTAB_XXXXX.select * into corresponding fields of itab_salesfrom bsidwhere bukrs = s_bukrs.authority-check object 'Z:FI-00001'id 'ACTVT' field '03'id 'BUKRS' field itab_sales-bukrsid 'GSBER' field itab_sales-gsber. "权限检查if sy-subrc ne 0. "权限检查未通过continue.endif.append itab_sales.clear itab_sales.endselect.ENDform. " SEL_DBTAB_XXXXX*&--------------------------------------------------------------**& form CMP_ITAB_XXXXX* text*---------------------------------------------------------------* * --> p1 text* <-- p2 text*---------------------------------------------------------------*form CMP_ITAB_XXXXX.ENDform. " CMP_ITAB_XXXXX*&--------------------------------------------------------------* *& form WRT_ITAB_RESULT*&--------------------------------------------------------------* * text*---------------------------------------------------------------* * --> p1 text* <-- p2 text*---------------------------------------------------------------* form WRT_ITAB_RESULT.* PERform WRT_ITAB_SUB.ENDform. " WRT_ITAB_RESULT*&--------------------------------------------------------------* *& form PAGE_HEADER*&--------------------------------------------------------------* * text*---------------------------------------------------------------* * --> p1 text* <-- p2 text*---------------------------------------------------------------* form PAGE_HEADER.ENDform. " PAGE_HEADER*&--------------------------------------------------------------* *& form INI_DATA*&--------------------------------------------------------------* * text*---------------------------------------------------------------* * --> p1 text* <-- p2 text*---------------------------------------------------------------* form INI_DATA.ENDform. " INI_DATA*&--------------------------------------------------------------**& form INI_SELECTION_SCREEN*&--------------------------------------------------------------** text*---------------------------------------------------------------** --> p1 text* <-- p2 text*---------------------------------------------------------------*form INI_SELECTION_SCREEN.ENDform. " INI_SELECTION_SCREEN*&--------------------------------------------------------------**& Include Z_X_XXXXXTOP*&--------------------------------------------------------------*REPORT Z_X_XXXXX .*-------------------声明系统字典对象----------------------------*TABLES: t001.*--------------------声明Selection-screen 变量-----------------*SELECTION-SCREEN BEGIN OF BLOCK B1WITH FRAMETITLE TEXT-001.SELECTION-SCREEN SKIP.SELECT-OPTIONS: S_BUKRS FOR T001-BUKRS MEMORY ID BUK. PARAMETERS: P_DATE LIKE SY-DATUM DEFAULT SY-DATUM.SELECTION-SCREEN END OF BLOCK B1.*--------------------声明全局变量-------------------------------**声明内表时，表名为ITAB_XXXX，后缀尽可能为关联DBTab或内表用途DATA: bldat like bsid-bldat.RANGES: R_FIELD FOR DBTAB-FIELD.说明：以上是模板程序的框架及说明，在R/3系统的开发环境中有该模板程序(Z_X_XXXXX)，建议编程序之前，先将该程序另存一新文件，再根据需要修改这新文件。
CppCodingStyleGuide poco代码规范
Applied Informatics C++ Coding Style Guide Rules and RecommendationsVersion 1.3Purpose of This DocumentThis document describes the C++ coding style employed by Applied Informatics.The document is targeted at developers contributing C++ source code to the products of Applied Informatics, including contributions to open-source projects like the POCO C++ Libraries.Copyright, Licensing, Trademarks, DisclaimerCopyright © 2006-2010, Applied Informatics Software Engineering GmbH. All rights reserved. This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit /licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.All trademarks or registered marks in this document belong to their respective owners. Information in this document is subject to change without notice and does not represent a commitment on the part of Applied Informatics. This document is provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the particular purpose. Applied Informatics reserves the right to make improvements and/or changes to this document or the products described herein at any time.AcknowledgementsThis work is based on various guidelines found on the internet, especially the rules and recommendations by Mats Henricson and Erik Nyquist. Also incorporated are ideas and recommendations from various other sources. See the Appendix for a list of recommended resources.Table of Contents1 Introduction (5)2 Terminology (6)3 General Recommendations (8)4 Source Files and Project Structure (9)4.1 Structure of Source Code 9 4.2 Naming Files 9 4.3 Project Structure 9 4.4 Whitespace 10 4.5 Comments 11 4.6 Header Files 125 Names (15)6 Style (18)6.1 Classes 18 6.2 Functions 19 6.3 Templates 20 6.4 Compound Statements 20 6.5 Flow Control Statements 20 6.6 Pointers and References 21 6.7 Miscellaneous 227 Classes (23)7.1 Access Rights 23 7.2 Inline Functions 23 7.3 Friends 24 7.4 Const Member Functions 25 7.5 Constructors and Destructors 25 7.6 Assignment Operator 27 7.7 Operator Overloading 28 7.8 Member Function Return Types 29 7.9 Inheritance 298 Class Templates (30)9 Functions (31)9.1 Function Arguments 31 9.2 Function Overloading 32 9.3 Formal Arguments 32 9.4 Return Types and Values 32 9.5 Inline Functions 33 9.6 Temporary Objects 33 9.7 General 3310 Constants (35)11 Variables (36)12 Pointers and References (37)13 Type Conversions (38)14 Flow Control (39)15 Expressions (41)16 Memory and Resources (42)17 Namespaces (44)18 Error Handling (45)19 Portability (46)20 References and Recommended Reading (47)21 Appendix: Documentation (49)21.1 General Conventions 49 21.2 Documenting Classes and Structs 49 21.3 Documenting Functions 50 21.4 Documenting Enumerations 51 21.5 Documenting Types 51 21.6 Libraries, Packages and Modules 5122 Appendix: Abbreviations (52)1IntroductionThe purpose of this document is to define one style of programming inC++. The rules and recommendations presented here are not final, butshould serve as a basis for continued work with C++. This collection of rulesshould be seen as a dynamic document; suggestions for improvements areencouraged. Suggestions can be made via e-mail to poco@.Programs that are developed according to these rules and recommendationsshould be:•correct•easy to maintain.In order to reach these goals, the programs should:•have a consistent style,•be easy to read and understand,•be portable to other architectures,•be free of common types of errors,•be maintainable by different programmers.Questions of design, such as how to design a class or a class hierarchy, arebeyond the scope of this document. Recommended books on these subjectsare indicated in the appendix entitled References.In order to obtain insight into how to effectively deal with the most difficultaspects of C++, the provided example code should be carefully studied. C++is a difficult language and there may be a very fine line between a feature anda bug. This places a large responsibility upon the programmer, as this isalways the case when using a powerful tool. In the same way as for C, C++allows a programmer to write compact and, in some sense, unreadable code.In order to make the code more compact, the examples provided do notalways follow the rules. In such cases, the broken rule is clearly indicated.2Terminology1.An identifier is a name used to refer to a variable, constant, functionor type in C++. When necessary, an identifier may have an internalstructure consisting of a prefix, a name, and a suffix (in that order).2. A class is a user-defined data type consisting of data elements andfunctions operating on that data. In C++, this may be declared as aclass; it may also be declared as a struct or a union. Variables definedin a class are called member variables and functions defined in a classare called member functions.3. A class/struct/union is said to be an abstract data type if it does nothave any public or protected member variables.4. A structure is a user-defined consisting of public member variablesonly.5.Public members of a class are member variables and memberfunctions that are accessible from anywhere by specifying an instanceof the class and the name.6.Protected members of a class are member variables and memberfunctions that are accessible by specifying the name within memberfunctions of derived classes.7. A class template defines a family of classes. A new class may becreated from a class template by providing values for a number ofarguments. These values may be names of types or constantexpressions.8. A function template defines a family of functions. A new functionmay be created from a function template by providing values for anumber of arguments. These values may be names of types or constantexpressions.9.An enumeration type is an explicitly declared set of symbolicintegral constants. In C++ it is declared as an enum.10. A typedef is another name for a data type, specified in C++ using atypedef declaration.11. A reference is another name for a given variable. In C++, the“address of” (&) operator is used immediately after the data type toindicate that the declared variable, constant, or function argument is areference.12. A macro is a name for a text string defined in a #define statement.When this name appears in source code, the compiler’s preprocessorreplaces it with the defined text string.13. A constructor is a function that initializes an object.14. A copy constructor is a constructor in which the only argument is areference to an object that has the same type as the object to beinitialized.15. A default constructor is a constructor with no arguments.16.An overloaded function name is a name used for two or morefunctions or member functions having different argument types. 17.An overridden member function is a member function in a baseclass that is re-defined in a derived class. Such a member function isdeclared virtual.18. A pre-defined data type is a type defined in the language itself,such as bool or int.19. A user-defined data type is a type defined by a programmer in aclass, struct, union, enum, or typedef definition or as aninstantiation of a class template.20. A pure virtual function is a member function for which nodefinition is provided. Pure virtual functions are specified in abstractbase classes and must be defined (overridden) in derived classes.21.An accessor is a function returning the value of a member variable.22. A mutator is a function modifying the value of a member variable.23. A forwarding function is a function doing nothing more thancalling another function.24. A constant member function is a function that must not modifydata members.25.An exception is a run-time program anomaly that is detected in afunction or member function. Exception handling provides for theuniform management of exceptions. When an exception is detected, it is thrown (using a throw expression) to the exception handler.26. A catch clause is code that is executed when an exception of a giventype is raised. The definition of an exception handler begins with thekeyword catch.27.An abstract base class is a class from which no objects may becreated; it is only used as a base class for the derivation of other classes.A class is abstract if it includes at least one member function that isdeclared as pure virtual.28.An iterator is an object which, when invoked, returns the next objectfrom a collection of objects.29.The scope of a name refers to the context in which it is visible.30. A compilation unit is the source code (after preprocessing) that issubmitted to a compiler for compilation (including syntax checking).3General RecommendationsRecommendation 1Optimize code only if you know for sure that you have a performanceproblem. Think twice before you begin. Then measure and think again.C++ compilers are pretty good at optimizing these days. So, source codethat “looks fast” does not necessarily produce faster object code. It only isharder to understand and maintain.As C.A.R. Hoare once said: Premature optimization is the root of all evil.Recommendation 2Always compile production code with at least a second compiler and on asecond platform. If the code has been developed with Microsoft Visual C++under Windows XP, compile and test the code with the GNU C++ compileron a Unix platform, and vice versa. Even better is testing with a thirdcompiler, e.g. HP ANSI C++ or Sun Forte C++. This brings to light subtleerrors and portability problems.Recommendation 3Always compile at the highest warning level possible. A lot of bugs can beavoided by paying attention to compiler diagnostics.Rule 1If this style guide leaves anything unclear, see how it has been done in theexisting code base and do it accordingly.4Source Files and Project Structure 4.1Structure of Source CodeRule 2Header (include) files in C++ always have the file name extension ".h".Rule 3Implementation files in C++ always have the file name extension ".cpp". 4.2Naming FilesRule 4Always give a file a name that is unique in as large a context as possible.A header file for a class should have a file name of the form <class name> +extension. Use uppercase and lowercase letters in the same way as in thesource code.Since class names must generally be unique within a large context, it isappropriate to utilize this characteristic when naming its header file. Thisconvention makes it easy to locate a class definition using a file-based tool.4.3Project StructureRule 5Every project (library or application) has its own directory with a well-defined structure.A project directory contains project files, make files, as well as otherdirectories for header files, implementation files, documentation and the testsuite.Figure 1 shows the directory hierarchy for a project.Figure 1: Project directory hierarchyA test suite is a project in itself and thus has the same general structure,within the testsuite directory. Since a test suite has no public headerfiles, there is no include directory in a test suite.Rule 6Public header files always go into the include directory or a subdirectorythereof. To avoid name clashes and for better comprehensibility, theinclude directory may contain subdirectories. For libraries, the includedirectory usually contains a subdirectory with the same name as the library.Rule 7All implementation files and non-public header files go into the srcdirectory.Rule 8All project files, make files and other support files not containing sourcecode go directly into the project directory.Recommendation 4If there is extra documentation for a project (e.g. specifications or standarddocuments), this documentation goes into a directory named doc.4.4WhitespaceRule 9In a header or implementation file, introductory comment, include guards,#include block, using block and function definitions are separated bytwo empty lines. This makes it easier to visually distinguish the variouselements.Rule 10The last line in an implementation or header file must be terminated by anewline. This is required by the C++ standard, but not enforced by mostcompilers.4.5CommentsRule 11Every file that contains source code must be documented with anintroductory comment that provides information on the file name, itsversion and its contents.Rule 12All files must include copyright information.Rule 13All comments are written in English.Rule 14Write a comment for every class, public/protected function andpublic/protected enum/typedef/struct. The standardization ofcomments makes it possible to automatically generate referencedocumentation from source code. This is used to keep source code anddocumentation together up-to-date. The format of these comments isdescribed in the Appendix.Rule 15Use // for comments.It is necessary to document source code. This should be compact and easy tofind. By properly choosing names for variables, functions and classes and byproperly structuring the code, there is less need for comments within thecode.Note that comments in header files are meant for the users of classes, whilecomments in implementation files are meant for those who maintain theclasses.All our code must be copyright marked. If the code has been developed overa period of years, each year must be stated.Comments are often said to be either strategic or tactical. A strategiccomment describes what a function or section of code is intended to do, andis placed before this code. A tactical comment describes what a single line ofcode is intended to do, and is placed, if possible, at the end of this line.Unfortunately, too many tactical comments can make code unreadable. Forthis reason, it is recommended to primarily use strategic comments, unlesstrying to explain very complicated code.If the characters //are consistently used for writing comments, then thecombination /* */ could be used to make comments out of entire sectionsof code during the development and debugging phases. C++, however, doesnot allow comments to be nested using /* */. So it is better to commentout large sections of code using the preprocessor (#if 0 ... #endif).Source files containing commented-out code sections must not be checkedin to the SCM repository, as this would confuse other developers workingwith that code.Example 1Boilerplate text to be included at the beginning of every header orimplementation file://// <FileName>.h//// $Id$//// Library: <LibraryName>// Package: <PackageName>// Module: <ModuleName>//// <One or two sentences describing what the header file is for. Can// be omitted in source (.cpp) files.>//// Copyright (c) 2006, Applied Informatics Software Engineering GmbH.// All rights reserved.//// <License Notice>//4.6Header FilesRule 16Every header file must contain a mechanism that prevents multipleinclusions of the file.Rule 17When the following kinds of definitions are used (in implementation files orin other header files), they must be included as separate header files:•classes that are used as base classes,•classes that are used as member variables,•classes that appear as return types or as argument types infunction/member function prototypes.•function prototypes for functions/member functions used in inline member functions that are defined in the file.Rule 18Definitions of classes that are only accessed via pointers (*) or references (&) shall not be included as header files. Forward declarations shall be used instead. The only exceptions are classes that are in another namespace.Rule 19Never specify relative paths (containing “.” and “..”) in #include directives.Rule 20Every implementation file must include the relevant files that contain: •declarations of types and functions used in the functions that are implemented in the file.•declarations of variables and member functions used in the functions that are implemented in the file.Rule 21Every implementation file must, before any other header files, include its corresponding header file. This ensures that header files are self sufficient.Rule 22Use the directive #include "filename.h"for user-prepared include files.Rule 23Use the directive #include <filename.h>for system and compiler-supplied header files only.Rule 24Compiler include paths always point to the include directory in a project directory. Therefore, if a header file is located in a subdirectory of the include directory, it must be included with #include “dir/filename.h”. As a positive side effect, this avoids name clashes if different projects have a header file with the same name.The easiest way to avoid multiple includes of files is by using an#ifndef/#define block in the beginning of the file and an #endif at theend of the file.The number of files included should be minimized. If a file is included in aninclude file, then every implementation file that includes the second includefile must be re-compiled whenever the first file is modified. A simplemodification in one include file can make it necessary to re-compile a largenumber of files.When only referring to pointers or references to types defined in a file, it isoften not necessary to include that file. It may suffice to use a forwarddeclaration to inform the compiler that the class exists. Another alternativeis to precede each declaration of a pointer to the class with the keywordclass.Example 2Using include guards to prevent multiple inclusions of a header file:#ifndef Foundation_SharedPtr_INCLUDED#define Foundation_SharedPtr_INCLUDED#include "Poco/Foundation.h"...#endif // Foundation_SharedPtr_INCLUDED5NamesRule 25Every class library must define a unique namespace for its globally visibleidentifiers.Rule 26The identifier of every globally visible class, enumeration type, typedefinition, function, constant, and variable in a class library must be insidethe class library’s namespace.Rule 27The names of variables, and functions begin with a lowercase letter.Rule 28The names of abstract data types, classes, structures, types, and enumeratedtypes begin with an uppercase letter.Rule 29In names that consist of more than one word, the words are written togetherand each word that follows the first begins with an uppercase letter. 1Rule 30Global names must not begin with one or two underscores (“_” or “__”).This is forbidden by the C++ standard as such names are reserved for use bythe compiler.Rule 31With the exceptions of constants and enumeration values, there are nounderscores in names (after the first character of the name). 2Rule 32Do not use type names that differ only by the use of uppercase andlowercase letters.1 This is also known as camel-case.2 The leading underscore in names of private and protected member variables (see Rule 33) does not count here.Rule 33The name of a private or protected member variable begins with a singleunderscore.3 This is the only underscore in such a name (see Rule 31).Rule 34The names of constants and enumeration values are all uppercase. In namesthat consist of more than one word, these words are separated by underscorecharacters.Rule 35Encapsulate global variables and constants, enumerated types, and typedefsin a class.Recommendation 5Names should be self-descriptive yet as brief as possible. Cryptic abbreviatednames are as hard to read as well as too long ones.Recommendation 6Names should be pronounceable. It is hard to discuss something that cannotbe pronounced.Recommendation 7Names should not include abbreviations that are not generally accepted. Alist of generally accepted abbreviations can be found in the Appendix.Recommendation 8A variable holding a pointer should be prefixed with “p”. A value holding areference should be prefixed with “r”. A variable holding an iterator shouldbe prefixed with “it”.Recommendation 9Apart from the cases in Recommendation 8, avoid encodings in names.Encoded names require deciphering. Especially, avoid type-encoded variablenames (Petzold-style Hungarian notation like lpcszName).3 There are different opinions regarding the validity of leading underscores in class member names. The C++ standard explicitly states that leading underscores are not allowed in global names. Class members are not global, therefore this rule does not apply to them. Experience with a variety of different compilers does not show any problems. A commonly used alternative is to append an underscore at the end of a member variable name.Recommendation 10Be consistent. If something is a name it should be a name everywhere it isused (not, e.g. an id somewhere else).Example 3Identifier names in a class declaration (comments have been removed): class Net_API HTTPRequest: public HTTPMessage{public:HTTPRequest();HTTPRequest(const std::string& version);HTTPRequest(const std::string& method, const std::string& uri);virtual ~HTTPRequest();void setMethod(const std::string& method);const std::string& getMethod() const;void write(std::ostream& ostr) const;void read(std::istream& istr);static const std::string HTTP_GET;static const std::string HTTP_HEAD;static const std::string HTTP_PUT;static const std::string HTTP_POST;static const std::string HTTP_OPTIONS;static const std::string HTTP_DELETE;static const std::string HTTP_TRACE;static const std::string HTTP_CONNECT;private:enum Limits{MAX_METHOD_LENGTH = 32,MAX_URI_LENGTH = 4096,MAX_VERSION_LENGTH = 8};std::string _method;std::string _uri;};6Style6.1ClassesRule 36The public, protected, and private sections of a class are declared inthat order (the public section is declared before the protected sectionwhich is declared before the private section).Rule 37With the exception of templates where current compiler technologycommands it, member functions are never defined within the classdefinition.Rule 38Inline functions are defined in a separate block following the classdeclaration.Recommendation 11If a member variable has an accessor, but not a mutator, the accessor has thesame name as the variable, sans the underscore prefix. If a member variablehas both an accessor and a mutator, the accessor name has a get prefix andthe mutator name has a set prefix.By placing the public section first, everything that is of interest to a user isgathered in the beginning of the class definition. The protected section maybe of interest to designers when considering inheriting from the class. Theprivate section contains details that should have the least general interest.A member function that is defined within a class definition automaticallybecomes inline. Class definitions are less compact and more difficult to readwhen they include definitions of member functions. It is easier for an inlinemember function to become an ordinary member function if the definitionof the inline function is placed outside of the class definition.Example 4Defining an inline function:class Foundation_API UUID{public:...bool operator == (const UUID& uuid) const;bool operator != (const UUID& uuid) const;bool operator < (const UUID& uuid) const;bool operator <= (const UUID& uuid) const;bool operator > (const UUID& uuid) const;bool operator >= (const UUID& uuid) const;...};//// inlines//inline bool UUID::operator == (const UUID& uuid) const{return compare(uuid) == 0;}inline bool UUID::operator != (const UUID& uuid) const{return compare(uuid) != 0;}...Example 5Accessors and mutators:class Property{public:Property(const std::string& name);Property(const Property& prop);~Property();Property& operator = (const Property&);const std::string& name();void setValue(const std::string& value);const std::string& getValue() const;private:Property();std::string _name;std::string _value;};6.2FunctionsRecommendation 12When declaring functions, the leading parenthesis and the first argument (ifany) are written on the same line as the function name. If space andreadability permit, other arguments and the closing parenthesis may also bewritten on the same line as the function name. Otherwise, each additionalargument is written on a separate line, indented with a single tab (with theclosing parenthesis directly after the last argument).Example 6Long function declarations:DateTime& assign(int year,int month,int day,int hour = 0,int minute = 0,int second = 0,int millisecond = 0,int microseconds = 0);Recommendation 13Always write the left parenthesis directly after a function name. There is nospace between the function name, the opening brace and the first argumentdeclaration. Also there is no space between the last argument and the closingparenthesis.6.3TemplatesRule 39The template keyword, together with the template argument list, is writtenon a separate line before the following class or function definition.6.4Compound StatementsRecommendation 14Braces ("{}") enclosing a block are placed in the same column, on separatelines directly before and after the block.The placement of braces seems to have been the subject of the greatestdebate concerning the appearance of both C and C++ code. We recommenda style that, in our opinion, gives the most readable code. Other styles maywell provide more compact code.6.5Flow Control StatementsRecommendation 15There is always a space between the flow control statement’s keyword andthe opening parenthesis of the control expression. There is no space betweenthe opening parenthesis and the expression. There is also no space betweenthe expression and the closing parenthesis.Recommendation 16The flow control primitives if, else, while, for and do should befollowed by a block, even if it is an empty block, or consisting of only onestatement.At times, everything that is done in a loop may be easily written on one linein the loop statement itself. It may then be tempting to conclude thestatement with a semicolon at the end of the line. This may lead tomisunderstanding since, when reading the code, it is easy to miss such asemicolon. Also, the semicolon could be deleted by accident, leading to ahard-to-find bug. It seems to be better, in such cases, to place an emptyblock after the statement to make completely clear what the code is doing.Even more better is to avoid this style altogether.In certain cases, a code that is more compact might be better readable thancode with many blocks containing only a single statement. As a general rule,readability must always be preferred to strict style adherence.Example 7Blocks and single statements:int ASCIIEncoding::convert(int ch, unsigned char* bytes, int length) const {if (ch >= 0 && ch <= 127){*bytes = (unsigned char) ch;return 1;}else return 0;}Example 8Single-line flow control statements can improve readability by keeping thecode more compact:void MessageHeader::splitParameters(const std::string& s,std::string& value,NameValueCollection& parameters){value.clear();parameters.clear();std::string::const_iterator it = s.begin();std::string::const_iterator end = s.end();while (it != end && isspace(*it)) ++it;while (it != end && *it != ';') value += *it++;Poco::trimRightInPlace(value);if (it != end) ++it;splitParameters(it, end, parameters);}6.6Pointers and ReferencesRecommendation 17The dereference operator “*” and the address-of operator “&” should bedirectly connected with the type names in declarations and definitions.The characters “*” and “&” should be written together with the types ofvariables instead of with the names of variables in order to emphasize that。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目录
1SAP模块清单 (2)
2程序类型 (2)
3命名规范 (3)
3.1程序中变量命名 (3)
4程序说明 (5)
4.1程序头部注释 (5)
4.2子程序头的注释 (6)
4.3代码块的注释 (6)
4.4在线文件 (6)
1SAP模块清单
2程序类型
3命名规范
3.1程序中变量命名
ABAP Queries
Program Attributes
4程序说明
4.1程序头部注释
* PROGRAM ID/NAME: DATE WRITTEN:
* AUTHOR'S NAME: LAST UPDATE:
* PROGRAM TITLE:
* PROJECT NAME:
* VERSION: 1.0
*------------------------------------------------------------------*
* DESCRIPTION:
*------------------------------------------------------------------*
* INCLUDE: N/A
*------------------------------------------------------------------*
* CALLS: (RFC AND BPI)
*------------------------------------------------------------------*
* TABLE:
*------------------------------------------------------------------*
* CHANGE HISTORY
*------------------------------------------------------------------*
* DATE | PROGRAMMER | Flag
***DESCRIPTION
*********************************************
(说明：Flag是用来查找本次所修改的所有内容的依据，建议用M.YYYY.MM.DD --- M （Modify）YYYY （年）MM（月）DD（天），在程序修改起始位置前一行加上：*BO – M.YYYY.MM.DD Description ，在程序修改结尾加上*EO – M.YYYY.MM.DD Description )
4.2子程序头的注释
*********************************************
*功能说明 *
*参数说明 *
*********************************************
4.3代码块的注释
*********************************************
*功能说明 *
*********************************************
4.4在线文件
∙Purpose of the Program: 程序的目的
∙Inputs to the Program: 输入参数的说明
∙Processing Description: 粗线条的处理说明（high level description ）
∙Outputs from the Program: 输出结果说明。