Sometimes the choice is not ours. This could be a complex algorithm or a particular workflow that is difficult to code without getting tricky. It will help people that look the program later to know why this was done and what the code is attempting to accomplish.
As programmers we need to remember out job is NOT to make our job easier. If the solution that works for the client requires we get 'tricky' in code then we do. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Serguei Poliakov > Sent: Thursday, September 29, 2005 5:10 AM > To: [email protected] > Subject: Re: [U2] Good Programming Practice Question......... > > I thinks the better to say - if the code looks tricky, there is something > wrong with it. The advice would be - don't write tricky-looking code. :) > > Serguei > > ----- Original Message ----- > From: "Dianne Ackerman" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, September 27, 2005 7:56 PM > Subject: Re: [U2] Good Programming Practice Question......... > > > > I like these and would add another one - Add comments to tricky-looking > > code! > > -Dianne > > > > David A. Green wrote: > > > > >I've been teaching UniBasic for over 10 years and here are some of the > > >methods I teach: > > > > > >* Subroutines should only have one job. > > >* Subroutines should be short. (less than 10 lines) > > >* Subroutines should have one entrance and one exit. > > >* Use meaningful variable names and subroutine names. > > >* Be consistent in your naming conventions. > > >* Don't hard code Numbers, Strings, or Attributes. > > >* Use CASE over IF...THEN when there are more than two options. > > >* Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. > > >* Use REMOVE to traverse a dynamic array. > > >* Use a Simple Variable on Conditional Statements. > > >* Use UniData Internal Variables whenever possible; i.e. @AM, @VM, > @DATE. > > > > > >Thank you, > > >David A. Green > > >DAG Consulting > > >(480) 813-1725 > > >www.dagconsulting.com > > > > > > > > >-----Original Message----- > > >From: [EMAIL PROTECTED] > > >[mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff > > >Sent: Tuesday, September 27, 2005 8:23 AM > > >To: [email protected] > > >Subject: [U2] Good Programming Practice Question......... > > > > > >Hi All, > > > > > >We are planning to train some of our new programmers > > >to use good programming practices when using U2 Basic. > > >I can remember in Unidata days us having some tech > > >support documents that talked about this. Example such > > >as when is the best time to use CASE instead IF & ELSE > > >or not to use GOTO statments. > > > > > >I am sure some of you may have some input in this > > >topic. If you have some documents, notes or thoughts > > >on this, can you please share with us? > > > > > >When I get all the technical tips, I can compile this > > >to a document and share with our new programmers as > > >well as U2 listserver community. > > > > > >Thanks > > > > > >Mohamed > > ------- > > u2-users mailing list > > [email protected] > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
