旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � September 1992 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Notes The most frequently discussed topic in many computer magazines targeted at programmers (e.g. Computer Language) is Computer Aided Software Engineering (CASE). There are literally hundreds of CASE tools on the market today. I am mystified at the volume of marketing noise being made about these products. Are these products selling well? Are people actually using them? My personal experience is that application systems are being designed in the same fashion that they have been designed for the last 15 years. There may be some new tools used for documenting the design process, but the fundamental analysis and design process is the same. To my thinking, the fundamental change will occur when a design can be entered into a CASE tool, and by pressing the GO button, a fully-operational application system pops out - not design specs or prototype screens, but the actual code and software that will be used in production. Some CASE tools can do this now for very simple applications. I am looking for the CASE tool that can generate a system for either character mode or a GUI applications that is as complicated as the order entry system for a Fortune 500 company. Does any reader know of such a CASE tool - or anything that is even close? The purpose of this rambling does have something to do with DATABUS and DB/C. It is my fundamental belief that DB/C is an excellent intermediate language for a CASE tool that creates real systems. DB/C is portable and extensible. Compilation and execution speed is better than most existing 4GL's. DB/C contains an absolutely portable ISAM, but also interfaces with SQL databases as well as other ISAM systems. DB/C 8.0 will provide GUI programming while maintaining its portability. If only a major CASE tool vendor could be convinced... What do you think? The first article in this month's DB/C Newsletter deals with the issue of programming style. It is an issue that many DB/C programmers have not spent enough time considering. The impact that good, consistent programming style can have on productivity is actually quite large. I hope that the article gets you thinking about this most important aspect of your profession. We are starting to run out of obvious tips to include in the TIPS column. If you know of anything that might be appropriate for the TIPS column, please communicate it to me for inclusion in a future DB/C Newsletter. DNW Programming Style At first glance, the issue of DATABUS programming style would seem to be rather mundane. It also would seem that because DATABUS is an older, more established language, and that a defacto style would have evolved and everyone would be programming in it. This is not the case. There are two major style issues that are causing problems for DATABUS programmers around the world. These issues are case (upper/lower) and spacing (indentation or tabs). DATABUS has traditionally been an upper case only language. All verbs and labels were always specified in upper case. This came about because very early terminals were incapable of displaying lower case. Other older programming languages like FORTRAN also historically are upper case, but newer languages were not limited by the hardware of the their infancy. Older languages tend to adopt features of the newer languages to keep programmers programming in them. Languages that don't adopt newer features tend to die (i.e. PL/1). C and PASCAL are examples of newer languages that have come into general use. The typical styles of these languages use lower case extensively (C uses lower case almost exclusively). Should DATABUS programs use lower case? Here are various ways of coding the same program - you be the judge. . ALL UPPER CASE VERSION WORK1 DIM 10 SUBTOTAL FORM 6.2 GRANDTOT FORM 6.2 ADD SUBTOTAL TO GRANDTOT DISPLAY *ES, SUBTOTAL, "*": *N, GRANDTOTAL, "**": *N, WORK80 . CASE VARIANT 1 Work80 DIM 80 SubTotal FORM 6.2 GrandTot FORM 6.2 ADD Subtotal to GrandTot DISPLAY *ES, SubTotal, "*": *N, GrandTot, "**": *N, Work80 . CASE VARIANT 2 WORK80 dim 80 SUBTOTAL form 6.2 GRANDTOT form 6.2 add SUBTOTAL to GRANDTOT display *es, SUBTOTAL, "*": *n, GRANDTOT, "**": *n, WORK80 . CASE VARIANT 3 Work80 dim 80 SubTotal form 6.2 GrandTot form 6.2 add SubTotal to GrandTot display *es, SubTotal, "*": *n, GrandTot, "**": *n, Work80 . CASE VARIANT 4 Work80 dim 80 Subtotal form 6.2 Grandtot form 6.2 add Subtotal to Grandtot display *es, Subtotal, "*": *n, Grandtot, "**": *n, Work80 . CASE VARIANT 5 work80 dim 80 subtotal form 6.2 grandtot form 6.2 add subtotal to grandtot display *es, subtotal, "*": *n, grandtot, "**": *n, work80 There are pros and cons for each of the styles shown above. The all upper case version and the all lower case version are the easiest to type because the SHIFT key seldom needs to be pressed. The readability of each variant depends primarily on personal preference. The spacing (or indentation) style issue is more complex. Traditional DATABUS indents verbs to line position 10 and operands to line position 20. The only variations in traditional DATABUS were where to start the comment. Comments started in 30, or 40 or some constant number of blank spaces after the last operand. Incorporation of modern flow control verbs (IF/ELSE/ENDIF and LOOP/REPEAT) into DATABUS caused major problems with traditional indenting. Here are just a few of the possibilities: . TRADITIONAL SPACING WORKDIM DIM 3 DISPLAY *RESETSW LOOP KEYIN *ES, *HON, "PLEASE ENTER THE CODE (AAA OR BBB)", *HOFF: *KCON, WORKDIM IF (WORKDIM = "AAA") CHECK FOR AAA CODE CALL PROCESSAAA DO AAA PROCESSING ELSE IF (WORKDIM = "BBB") CHECK FOR BBB CODE CALL PROCESSBBB DO BBB PROCESSING ELSE DISPLAY "THE VALUE ENTERED IS INCORRECT", *W ENDIF REPEAT . SPACING VARIANT 1 WORKDIM DIM 3 DISPLAY *RESETSW LOOP KEYIN *ES, *HON, "PLEASE ENTER THE CODE (AAA OR BBB)", *HOFF: *KCON, WORKDIM IF (WORKDIM = "AAA") . CHECK FOR AAA CODE CALL PROCESSAAA . DO AAA PROCESSING ELSE IF (WORKDIM = "BBB") . CHECK FOR BBB CODE CALL PROCESSBBB . DO BBB PROCESSING ELSE DISPLAY "THE VALUE ENTERED IS INCORRECT", *W ENDIF REPEAT . SPACING VARIANT 2 WORKDIM DIM 3 LOOP KEYIN *ES, *HON, "PLEASE ENTER THE CODE (AAA OR BBB)", *HOFF: *KCON, WORKDIM IF (WORKDIM = "AAA") CALL PROCESSAAA ELSE IF (WORKDIM = "BBB") CALL PROCESSBBB ELSE DISPLAY "THE VALUE ENTERED IS INCORRECT", *W ENDIF REPEAT . SPACING VARIANT 3 WORKDIM DIM 3 LOOP KEYIN *ES, *HON, "PLEASE ENTER THE CODE (AAA OR BBB)", *HOFF: *KCON, WORKDIM IF (WORKDIM = "AAA") . CHECK FOR AAA CODE CALL PROCESSAAA . DO AAA PROCESSING ELSE IF (WORKDIM = "BBB") . CHECK FOR BBB CODE CALL PROCESSBBB . DO BBB PROCESSING ELSE DISPLAY "THE VALUE ENTERED IS INCORRECT", *W ENDIF REPEAT The last variant also touches on a major issue: Do the operands follow the verb by one blank or are they aligned on a tab stop? If you think of DATABUS as sentences, in that a verb is followed by the objects that it operates on, then it makes sense to have the verb followed by one blank. Deeply nested IF statements are also handled well by the-one-blank-following- verb style. With any indenting of LOOP/REPEAT and IF/ELSE/ENDIF, the trailing comments do not stand out as well. Therefore, it might be advisable to leave them out completely. The following example combines CASE VARIANT 4, SPACING VARIANT 3, and moves the comments to the top of the section of code: Workdim dim 3 . If the code entered is AAA, then do AAA processing . If the code entered is BBB, then do BBB processing loop keyin *es, *hon, "PLEASE ENTER THE CODE (AAA OR BBB)", *HOFF: *kcon, Workdim if (Workdim = "AAA") call ProcessAAA else if (Workdim = "BBB") CALL ProcessBBB else display "THE VALUE ENTERED IS INCORRECT", *w endif repeat There is one other issue that comes up with the single space after verb style. Here are the two examples that show the issue: . CONTINUATION INDENT VARIANT 1 Worknum1 form 1 keyin *p=1:3, "1 Process AAA": *p=1:4, "2 Process BBB": *p=1:5, " Enter menu item number", Worknum1 if (Worknum1 = 1) call ProcessAAA else if (Worknum1 = 2) call ProcessBBB endif . CONTINUATION INDENT VARIANT 2 Worknum1 form 1 keyin *p=1:3, "1 Process AAA": *p=1:4, "2 Process BBB": *p=1:5, " Enter menu item number", Worknum1 if (Worknum1 = 1) call ProcessAAA else if (Worknum1 = 2) call ProcessBBB endif Should continuations of KEYIN, DISPLAY, WRITE, PRINT, etc. line up with the first operand on the line with the verb, or should continuations be at the tab position that is one level indented (in our example 5 spaces)? There is no right or wrong answer to any of these questions. The purpose of having a style of programming is to enhance readability which in-turn enhances maintainability. In the final analysis, personal preference (or your boss's personal preference) dictates programming style. Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips Tips The subject of this month's Tips column is modular programming. The main objective of modular programming is to decouple two sections of a program. Decoupling means to have no interaction between program elements such as variables, flags, screen position, etc. The following code is a good example of a HELP screen function implemented in a way that is completely decoupled with the main program: workchar1 char 1 hlp.flags char 4 hlp.traps char 200 hlp.state char 250 hlp.win char 2000 hlp.char1 char 1 . This is the main program trap Help noreset disable prior if F1 loop keyin *es, *p=35:5, "MAIN MENU": *p=28:6, "1 Start daily processing": *p=28:7, "2 Reports": *p=28:8, "3 End of day processing": *p=28:9, "Q Exit": *p=28:11, "Enter choice: ", workchar1; switch (workchar1) case "1" call Daily case "2" call Reports case "3" call End case "Q" or "q" stop default display "INVALID ENTRY", *w endswitch repeat . These are the processing routines Daily display *es, "DAILY PROCESSING", *w return Reports display *es, "REPORT PROCESSING", *w return End display *es, "END OF DAY PROCESSING", *w return . This Help routine that can be activated at any time during processing Help flagsave hlp.flags trapsave hlp.traps trapclr all enable statesave hlp.state display *setswall=5:16:20:60 winsave hlp.win keyin *bgcolor=*green, *color=*black, *es: *p=10:5, "THIS IS THE HELP BOX": *p=10:7, "Tap enter to continue", hlp.char1 winrestore hlp.win staterestore hlp.state disable traprestore hlp.traps flagrestore hlp.flags enable return The purpose of the flagsave, trapsave, statesave and winsave verbs in the Help routine is to save the current program state. The current program state is the values of the flags, the trap settings, the current cursor position, the current window boundary, the characters on the screen, etc. This allows the F1 key to be pressed at any place in the main program. The use of variables that all start with "hlp." makes sure that no variables are used in both the main program and the Help routine. ANSI Standard DATABUS and the book "The DATABUS Programming Language" The start of the public review period for the Draft Proposed ANSI Standard DATABUS document has been delayed again. The current target for approval by the appropriate committee is November 1992. If this target is met and all public review and official body work happens on schedule, then the DATABUS Standard will become an official ANSI Standard by November or December 1993. Dan Felder and Don Wills have written a book called "The DATABUS Programming Language". It is based on the current draft of the Standard DATABUS document. Anyone who programs in DATABUS should have a copy of this book, because it is the DATABUS "bible". Written in a clear, informal style, it is intended for self-paced learning and is filled with many examples. You can purchase it direct from Subject, Wills & Company for $35 plus $4 shipping inside the USA (actual costs are charged for shipping outside the USA). The book is available now. To order it, call Judi at (708) 572-0240. IDUG The International DATABUS Users Group (IDUG) has tentatively scheduled a conference and exposition for January 25-27 in Phoenix, Arizona. This is the only exclusively DATABUS get-together in the United States. Subject, Wills & Company will be there and we hope you will be too. DB/C Class Schedule The next DB/C class is scheduled to begin October 26 at the Oak Brook, Illinois office of Subject, Wills & Company.