RE: 4GL Query problem !

Programming like that (no globals or modular variables only paramerters being passed) remindes me of programming in COBOL. I hate to think about passing 100 + variables all over the program in and out of 50 different function just to get to the one I need them in. When I could have stored them in a nice neet global, or module variable. I do agree with you that they can be OVERUSED, but I do believe that they have an important part in programming and should not be avoided. Also naming pratices that were mentions are the best way.. m_test Modular variable g_test Global variable l_test Local variable gr_test Global Record ga_test global array and so on... This naming style keeps you from having to remember every detail of every variable. You see the naming style and know in a second that its just a local variable and wont mess up some global variable. Just and example. Matt C. POS Programmer > -----Original Message----- > From: Robert Taylor [SMTP:robertt@scotlegal.com] > Sent: Thursday, July 22, 1999 8:43 AM > To: informix-list@iiug.org > Subject: Re: 4GL Query problem ! > > You might think its good but personally I find it just a bit dumb. If > you > can't read it then its probably over complicated. Also , I think > global / > modular variables are a no no unless there is no other way , > everything > should be parameters. Arrays are the obvious exception. > > Tony Flaherty <aef@mfs.misys.co.uk> wrote in message > news:932635496.21678.0.nnrp-01.c1ed1f69@news.demon.co.uk... > > A good naming convention within 4GL is to prefix everything with a > letter > > indicating the scope of the variable, e.g. l_myvar for local, > m_myvar for > > modular etc. It makes the code easier to read and as an after > effect > > prevents you ever having to consider this type of ambiguity in SQL > > statements, well at least so long as you don't name your columns > l_colname > > ;o). > > > > > > -- > > --------------------------------------- > > Tony Flaherty aef@mfs.misys.co.uk > > Analyst Programmer > > Misys Financial Systems > > All statements and opinions are my own, > > Misys don't pay me enough to have opinions > > on their behalf > > > > . > > Art S. Kagel wrote in message <3795FCA9.E7D2CE90@bloomberg.net>... > > >Ramdas Gopinath wrote: > > >> > > >> Hi Nayan, > > >> Just check to see whether you have a variable defined with the > same > name. > > It > > >> is always better to prefix a column name with the table name or > the @. > > > > > >Correct. Just a note, using the tablename will not save you from > the > > >confusion that the @ is there to resolve if, as is common practice, > > >you have structures with the same names as the table declared 'LIKE > > ><tablename>' so it is alwasy good practive in 4GL to prefix column > > >names in where clauses with the at sign (@) or to religiously avoid > > >naming program objects after the database objects they map. > > > > > >Art S. Kagel > > > > > >> Gopi > > >> > > >> NayAn JaiN <nayan.jain@tatainfotech.com> wrote in message > > >> news:7n3l0u$7e7$1@news.xmission.com... > > >> > > > >> > Hi all, > > >> > > > >> > I have a silly question, but wasnt able to figure out what is > happening > > >> > and how is it happening. > > >> > > > >> > Here is a query statement that is written in a 4gl program. > > >> > > > >> > SELECT insp_periodicity > > >> > INTO g_insp_periodicity > > >> > FROM smm_insp_period > > >> > WHERE @insp_autho = gr_smrpm01.sti_iii_cd> > >> > > > >> > Please notice there is a "@" sign before field "insp_autho" > > >> > > > >> > now if this "@" sign is there then this query gives status = 0 > > >> > and if i remove this then it gives status = 100. > > >> > > > >> > What does this "@" sign means and how does this affect the > query. > > >> > > > >> > BTW, I wrote a dummy program with the same query. There it > works in > > both > > >> > the cases...means...with or without "@" sign, i get status = 0. > > >> > > > >> > But when i run the same query in dbaccess, i get a syntax error > at > "@" > > >> > sign. > > >> > > > >> > Cant figure out. > > >> > > > >> > TIA, > > >> > > > >> > With Regards > > >> > Nayan Jain ! > > >> > > > >> > > > >> > > > >> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > > >> > Ye Lamhe, Ye pal ham baraso yaad karenge ... > > >> > > > >

Uh oh! We're getting into the Religious Issue Zone here. The issues are not simple and in 4GL, at least, there are serious trade offs to not using Globals. OK good modular programming technique requires us to reduce or eliminate functional cohesion, the dependency of a function on the functions that call it or that it calls. The ONLY way to do this is to have NO globals at all and to pass every piece of data that a function needs to do its job as arguments or for the function to acquire them itself, ie by reading from a file or database. Now with a deeply nested well modularized program this is not easy but using structures and structure passing it is practical to do. There are many books, articles, and papers on this subject which outline the reasons for eliminating the three kinds of cohesion so 'nuff said here. At any rate good programmers avoid globals like the plague and only use them to pass information that is needed EVERYWHERE and so would be passed as an argument to every function. A good example might be a file handle for error logging though one could easily make an argument that a single error logging function is the only place that that handle needs to be known and creating such a function eliminates another global. To remind myself to limit my use of globals, and anyone who has seen the code for dbcopy.ec knows this, I always gang all my globals in one place and prefix the code section with a comment like: /* GLOBALS - I hate these things. */. That serves to remind me to limit my use of globals. Dbcopy.ec and the program it grew from, ul.ec, have fewer than 12 globals and modifying ul.ec from a binary export program to create dbcopy.ec a table copy program was not difficult at all nor was adding ARRAY FETCH technology to it later. That program is clean. Myschema on the other hand has many globals and most of the structure instantiations that data is FETCHed into are global. I am constantly fixing myschema bugs related to using the wrong global structure (the 'last' table record rather than the 'current' table record and vice versa) and adding SE engine support to it is turning into a nightmare because of this. The original code for myschema was written as a dbschema clone for use with Sybase databases by another programmer who while talented is not as careful to avoid cohesion and I am paying the maintenance price now. SE support is going to turn into a complete rewrite of the older sections of the code to eliminate the use of globals altogether and modularize that code as the newer code is modularized. I said in 4GL the issue is more difficult because there are greater trade offs. That is true. Because 4GL uses a program-stack based calling convention and always passes by value passing large numbers of arguments can increase the size of the stack and will significantly affect performance. So in 4GL we have to rely more on globals than we would like but we still need to do so responsibly and not throw them around willy nilly. As to naming conventions, I've always hated them myself but I will use them when they have a practical purpose. I refuse to name all my integers _i and doubles _d, etc., or to use MS's Czechoslovakian notation, or whatever it is called. Similarly I think that anyone should be willing to look in the GLOBALS file or section before naming a new variable and avoid unintentional clashes and intentional reuse of names in different scopes for different purposes, this is simply good practice and does not need naming conventions just diligence. On the other hand to name a variable p_columnname for a program variable in 4GL or h_columnname for hosts variables in ESQL/C to avoid having to remember whether you have to prepend an '@' to columns or ':' to hostvars is very practical and therefore makes life easier and makes my code more understandable and maintainable and thus I'm willing. Just my $0.02. Gee I haven't spouted on this subject since I stopped posting to the "C" news groups where I would get into fights with coders who claimed they no longer needed structured programming techniques because they had objects. But that's another lecture and even more off topic. Art S. Kagel "Carpenter, Matthew" wrote: > > Programming like that (no globals or modular variables only paramerters > being passed) remindes > me of programming in COBOL. I hate to think about passing 100 + > variables all over the program > in and out of 50 different function just to get to the one I need them > in. When I could have stored > them in a nice neet global, or module variable. > I do agree with you that they can be OVERUSED, but I do believe that > they have an important > part in programming and should not be avoided. > > Also naming pratices that were mentions are the best way.. > > m_test Modular variable > g_test Global variable > l_test Local variable > gr_test Global Record > ga_test global array > > and so on... This naming style keeps you from having to remember every > detail of every variable. > You see the naming style and know in a second that its just a local > variable and wont mess up some > global variable. Just and example. > > Matt C. > POS Programmer > > > -----Original Message----- > > From: Robert Taylor [SMTP:robertt@scotlegal.com] > > Sent: Thursday, July 22, 1999 8:43 AM > > To: informix-list@iiug.org > > Subject: Re: 4GL Query problem ! > > > > You might think its good but personally I find it just a bit dumb. If > > you > > can't read it then its probably over complicated. Also , I think > > global / > > modular variables are a no no unless there is no other way , > > everything > > should be parameters. Arrays are the obvious exception. > > > > Tony Flaherty <aef@mfs.misys.co.uk> wrote in message > > news:932635496.21678.0.nnrp-01.c1ed1f69@news.demon.co.uk... > > > A good naming convention within 4GL is to prefix everything with a > > letter > > > indicating the scope of the variable, e.g. l_myvar for local, > > m_myvar for > > > modular etc. It makes the code easier to read and as an after > > effect > > > prevents you ever having to consider this type of ambiguity in SQL > > > statements, well at least so long as you don't name your columns > > l_colname > > > ;o). > > > > > > > > > -- > > > --------------------------------------- > > > Tony Flaherty aef@mfs.misys.co.uk > > > Analyst Programmer > > > Misys Financial Systems > > > All statements and opinions are my own, > > > Misys don't pay me enough to have opinions > > > on their behalf > > > > > > . > > > Art S. Kagel wrote in message <3795FCA9.E7D2CE90@bloomberg.net>... > > > >Ramdas Gopinath wrote: > > > >> > > > >> Hi Nayan, > > > >> Just check to see whether you have a variable defined with the > > same > > name. > > > It > > > >> is always better to prefix a column name with the table name or > > the @. > > > > > > > >Correct. Just a note, using the tablename will not save you from@@