************************************* * * * DB/C Newsletter * * February 1995 * * * ************************************* Editor's Notes With this newsletter, we return to a topic that is relevant to everyone who programs with DB/C - programming style. Many programmers new to the profession are disinterested in programming in 'old fashioned' languages like COBOL and DATABUS. One of the reasons is that much of the existing code base of COBOL and DATABUS is written in upper case. On the Internet, when you write a message in upper case, you are considered to be shouting. Most programming languages taught in school are naturally programmed in lower case. To young programmers accustomed to lower case programs, traditional COBOL and DATABUS are ugly and not cool. Programming in lower case is just one of the recommadations in this month's article. We welcome any comments you have about DB/C programming usage and style. In this past month, the DB/C electronic mailing list began operation. The list is called 'dbclist'. Its purpose is to provide a public forum for discussion of all aspects of DB/C. To subscribe, send an email message to: majordomo@swc.com that contains this one line in the body: subscribe dbclist don.wills@swc.com DB/C Programming Usage and Style Recommendations The topic of programming style is a controversial one. Traditional programming style in the DATABUS (now PL/B) language was created more than twenty years ago. Many DB/C programmers still write programs in that style. The purpose of this article is to describe a DB/C programming usage and style that breaks with tradition and brings DB/C into the modern programming world. Here are the style recommendations: 1. All elements of the program (verbs, program labels, control codes, prepositions, etc.) are in lower case. 2. Trailing comments (found after the last operand of a statement) are only used on data definition statements. Trailing comments start at tab position of column 26. If they must start after column 26, they are preceded by one blank, not a tab. All other comments are on separate comment lines. Blank lines are used for visual breaks. 3. The appropriate preposition, not a comma, is used where either is acceptable. 4. When using a comma in a list or otherwise, one blank follows the comma and precedes the next operand. 5. All programs are written with indents at 6, 11, 16, 21, 26, etc. Tabs, not blanks, are used to cause indentation. One blank is used after the verb and before the first operand. Statement continuation lines are indented 1 more tab to right than the first line of the statement. Here are special indentation rules: if statement: following statements indent 1 more tab to the right else statement: lines up with matching if statement; following statements indent 1 more tab to the right endif statement: this and following statements line up with matching if statement for, loop statements: following statements indent 1 more tab to the right repeat statement: this and following statements line up with matching for or loop statement case, default statements: line up with matching switch; following statements indent 1 more tab to right endswitch statement: this and following statements line up with matching switch statement routine, lroutine statement: one blank follows the label and precedes the routine or lroutine verb compiler directives: verb is located at column 6 (1 preceding tab) 6. There is one blank after each unary operator. There is one blank before and after each binary operator. 7. Program labels, except those used on routine and lroutine statements, are placed on separate lines. Unreferenced program labels are not used. DB/C is a large language. By limiting the number of verbs and how they are used, programs are easier to understand and maintain. Here is a list of verbs and other constructs that should and should not be used: 1. Except for char, gchar, num, gnum, int and gint, use only the long form of a verb, not the abbreviation (for example use flagrestore, not flagrest). 2. Use num instead of form; use char instead of dim. 3. Do not use common data area variables; use global variables instead. 4. Use only the conditional compiler directives that start with '%'; do not use the others (ifeq, xif, etc.). 5. Do not use the define compiler directive. 6. Do not use arithmetic verbs (add, compare, sqrt, etc.); use expressions instead. 7. Use the goto statement infrequently, if at all. 8. Do not use the branch and perform statements. 9. Do not use the while and until statements or operands. 10. Use the if operand only with break, continue, else, trap and goto; do not use the if operand on call, return and stop. 11. Use the 'and', 'or' and 'not' operator words, not '&', '|' and '!'; use 'or' in the case statement, not '|'. 12. Always use the equal sign in control codes (*p=1:1, not *p1:1). 13. Do not use the *+ and *- control codes; use their equivalents. 14. Do not use the trap or goto statements for handling keystrokes except to do interrupt processing with the trap statement; instead use the getendkey statement in conjunction with the keyin statement. 15. Do not use the tabbed versions of the read, write and update statements. 16. Do not use the weof statement. 17. Use only the form of the print statement that contains a pfile variable. Some of these usage and style recommendations may seem arbitrary or unimportant. However, the purpose of these recommendations is to make DB/C programs maintainable and acceptable to programmers of today and tomorrow. DB/C Class Schedule The next DB/C class is scheduled for April, 1995. The class is held in the Oak Brook, Illinois office of Subject, Wills and Company. For more information, contact Judi Tamkevic via email at dbc@swc.com or via telephone at (708) 572-0240.