ChinaITLab 
2003-2-19 
|
Professional programmers appreciate the importance of standards in developing programs that are readable, understandable, and maintainable. The issue of programming style goes beyond any one language, but the introduction of the RPG IV syntax demands that we Follow these standards to write readable, understandable, and maintainable RPG IV programs reexamine standards of RPG style. With that in mind, here are some simple rules of thumb you can use to ensure that bad code doesn抰 happen to good RPG software construction. 1.0 Comments Good programming style can serve a documentary purpose in helping others understand the source code. If you practice good code-construction techniques, you抣l find that "less is more" when it comes to commenting the source. Too many comments are as bad as too few. 1.1 Use comments to clarify ?not echo ?your code. Comments that merely repeat the code add to a program抯 bulk, but not to its values. In general, you should use comments for just three purposes: to provide a brief program or procedure summary to give a title to a subroutine, procedure, or other section of code to explain a technique that isn抰 readily apparent by reading the source 1.2 Always include a brief summary at the beginning of a program or procedure. This prologue should include the following information: a program or procedure title a brief des cription of the program抯 or procedure抯 purpose a chronology of changes that includes the date, programmer name, and purpose of each change a summary of indicator usage a des cription of the procedure interface (the return values and parameters) an example of how to call the procedure 1.3 Use consistent "marker line" comments to divide major sections of code. For example, you should definitely section off with lines of dashes or asterisks the declarations, the main procedure, each subroutine, and any subprocedures. Identify each section for easy reference. 1.4 Use blank lines to group related source lines and make them stand out. In general, you should use completely blank lines instead of blank comment lines to group lines of code, unless you抮e building a block of comments. Use only one blank line, though; multiple consecutive blank lines make your program hard to read. 1.5 Avoid right-hand "end-line" comments in columns 81-100. Right-hand comments tend simply to echo the code, can be lost during program maintenance, and can easily become "out of synch" with the line they comment. If a source line is important enough to warrant a comment, it抯 important enough to warrant a comment on a separate line. If the comment merely repeats the code, eliminate it entirely. 2.0 Declarations With RPG IV, we finally have an area of the program source in which to declare all variables and constants associated with the program. The D-specs organize all your declarations in one place. 2.1 Declare all variables within D-specs. Except for key lists and parameter lists, don抰 declare variables in C-specs ?not even using *LIKE DEFN. Define key lists and parameter lists in the first C-specs of the program, before any executable calculations. 2.2 Whenever a literal has a specific meaning, declare it as a named constant in the D-specs. This practice helps document your code and makes it easier to maintain. One obvious exception to this rule is the allowable use of 0 and 1 when they make perfect sense in the context of a statement. For example, if you抮e going to initialize an accumulator field or increment a counter, it抯 fine to use a hard-coded 0 or 1 in the source. 2.3 Indent data item names to improve readability and document data structures. Unlike many other RPG entries, the name of a defined item need not be left-justified in the D-specs; take advantage of this feature to help document your code: D ErrMsgDSDS DS D ErrPrefix 3 D ErrMsgID 4 D ErrMajor 2 OVERLAY(ErrMsgID:1) D ErrMinor 2 OVERLAY(ErrMsgID:3) 2.4 Use length notation instead of positional notation in data structure declarations. D-specs let you code fields either with specific from and to positions or simply with the length of the field. To avoid confusion and to better document the field, use length notation consistently. For example, code D RtnCode DS D PackedNbr 15P 5 instead of D RtnCode DS D PackedNbr 1 5 2.4.1 Use positional notation only when the actual position in a data structure is important. For example, when coding the program status data structure, the file information data structure, or the return data structure from an API, you抎 use positional notation if your program ignores certain positions leading up to a field or between fields. Using positional notation is preferable to using unnecessary "filler" variables with length notation: D APIRtn DS D PackedNbr 145 152P 5 In this example, to better document the variable, consider overlaying the positionally declared variable with another variable declared with length notation: D APIRtn DS D Pos145 145 152 D PackNbr 15P 5 OVERLAY(Pos145) 2.4.2 When defining overlapping fields, use the OVERLAY keyword instead of positional notation. Keyword OVERLAY explicitly ties the declaration of a "child" variable to that of its "parent." Not only does OVERLAY document this relationship, but if the parent moves elsewhere within the program code, the child will follow. 2.5 If your program uses compile-time arrays, use the **CTDATA form to identify the compile-time data. This form effectively documents the identity of the compile-time data, tying the data at the end of the program to the array declaration in the D-specs. The **CTDATA syntax also helps you avoid errors by eliminating the need to code compile-time data in the same order in which you declare multiple arrays. 3.0 Naming Conventions Perhaps the most important aspect of programming style deals with the names you give to data items (e.g., variables, named constants) and routines. 3.1 When naming an item, be sure the name fully and accurately describes the item. The name should be unambiguous, easy to read, and obvious. Although you should exploit RPG IV抯 allowance for long names, don抰 make your names too long to be useful. Name lengths of 10 to 14 characters are usually sufficient, and longer names may not be practical in many specifications. When naming a data item, describe the item; when naming a subroutine or procedure, use a verb/object syntax (similar to a CL command) to describe the process. Maintain a dictionary of names, verbs, and objects, and use the dictionary to standardize your naming conventions. 3.2 When coding an RPG symbolic name, use mixed case to clarify the named item抯 meaning and use. RPG IV lets you type your source code in upper- and lowercase characters. Use this feature to clarify named data. For RPG-reserved words and operations, use all uppercase characters. 3.3 Avoid using special characters (e.g., @, #, $) when naming items. Although RPG IV allows an underscore (_) within a name, you can easily avoid using this "noise" character if you use mixed case intelligently. Historically, indicators have been an identifying characteristic of the RPG syntax, but with RPG IV they are fast b | |
 相关文章 |
热门文章 |
|
| DB2新版本把数据管理推向信息管理 ibm主机系统维护--含双机 网络是核心——IBM看下一代技术 电信领域概述 Aptiva -- 如何确认我的机器的型号和产品序… 服务器 -IBM ServerRAID卡的配置 iSCSI技术简介 IBM的存储备份解决方案 Lotus Notes Domino 的介绍 Lotus/Notes在开发办公自动化系统中应用一例 |
| 文章评论 | |||