FUNCTION NUMBERING 1/2

I> From: ingeldew@aladdin.co.uk (Dave Ingledew) >Our shop is currently involved in a huge debate regarding numbering of >Informix functions. It seems that the COBOL guys like it and the >Informix experienced don't. I think it's a lousy idea. >I wonder if anyone out there has ever seen numbered Informix functions? >If so, did you do any maintenance of that code? What did you think of >numbered functions? Did it speed up construction/maintenance or slow it >down? I> I've been using numbered functions for some time now and after the > initial shock they can be very useful. I> They use a mixture of letters and numbers e.g. > a_000_initialize_variables() > a_010_initialize_arrays() I> b_000_new_record() > b_010_Insert_new_record() I> z_000_load_browse_array() I> When programs are very large 1000 plus lines this form of function > identification really helps to find them in a printout. That is > assuming they are kept in alphabetical/numerical order within the > program or module. For that means, I have created a print macro which prints a .4gl source file with the file name in the top left of the page, the current function name in the top right, and a line separating this "page header" from the main text. At the bottom, I print the date and time the file was printed in the lower left, and the page number in the lower right. This "page footer" is separated from the main text by a line above it. In the main text, I print every function in bold 12pt courier. The rest of the text is plain 10pt courier. It's easy to flip through pages to find the function you want using the page header, to eyeball text for bold to find a function, and to refer others to a specific page if you find a function before them. Since Informix functions can vary greatly in length, even if the functions are numbered, there's no way of knowing on what page a function will reside. I> I've extended the Mach4 system in that if a program is split into > several modules I will use a_000 etc in the main module and each > subsequent module will have the number incremented by 100 so the next > module would have functions a_100_ . The next module functions a_200 > and so on. I> This means that when you call a 100 function from the main module you > know not to look in the main module but in the next module you wrote > etc. At our site, we have proposed a shop standard of appending the file name to the function name. We already have a standard that the comment header of every 4gl file must state what functions are called and where they reside. I> Mach4 also introduced me to the concept of variable prefixes e.g > w_counter, w_amount, w_cost etc. By using the prefix you never have to > worry about reserved words. Again I've enlarged the concept, I use g_ > for global variables i.e. g_counter and f_ for variables defined in > functions i.e f_num_times. It becomes very obvious when using this > system which variables are only affected within a function and which > will have an effect throughout the program. I also use prefixes for > window names w_input_window and for cursor names c_search_stock. Our shop standard is similar for variable names. We use g, m, l, and a for global, module, local and argument, respectively. We also use c, dc, d, dt, i, f, l, m, r, si, sf for character, decimal, date, datetime, integer, float, like, money, record, smallint and smallfloat, respectively. Further, we have standard abbreviations for some 1400 words, so: A global character might be: gc_rpt_dest A module level date might be: md_end_dt etc. It was proposed that windows be preceded with w_, cursors with c_ and a few other things with similar prefixes, however, these buy nothing, since a window name is only used in a window statement, a cursor name only in a cursor statement, etc. z [ Continued In Next Message... ] --- ~ SPEED 1.40 [NR] ~