Cleaning up stuff -

Richard Kreiss rkreiss at verizon.net
Thu Oct 29 08:54:40 PDT 2009 

Top post:

John,

Long ago I stopped trying to put everything on one line even when there was
room.  Breaking things up makes the code more readable. For instance, if I
am creating an array and have NOT put the dim statement at the top of the
processing table, I will dim foobar() on one line and then set the elements
on the next line(s).  If it is menu, each element is set on a separate line.
Makes for easier reading and you have a quick visual of what the menu will
look like.

Subroutines, start with a short comment as to what it is for and the first
line is started at the left margin.  The next few line are indented 1 tab
space and the last line is at the left margin again.  Easier to read and
debug, if necessary.

With the expansion of the number of programming lines and the ability to
call routines, we really don't have to cram as much as possible on each line
of code.

You are right, spacing and long variables do make things easier to read. I
still use dummy variables to handle more mundane situations such as with a
listbox or manually created lookups.

Now for your example, I would have used bal_end_of_year or balance_eoy. :-)

One other thing I have done for over 15 years is use field names rather than
field numbers where possible.  The precursor to long variables.  Again makes
the code more readable.  

Richard




> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
[mailto:filepro-
> list-bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of John
Esak
> Sent: Wednesday, October 28, 2009 8:08 PM
> To: 'Nancy Palmquist'
> Cc: 'filePro List'
> Subject: RE: Cleaning up stuff -
> 
> Thanks,
> Well, you know how you get attached to processes you've written that work
> really well. That's how I feel about this simple use of the declare'd
> variable  slash.  It looks good and sounds good and lets you "read" the
code
> very easily.  But, a lot of times, you end up not being able to fit
> everything on one line so it becomes necessary to shorten the perfect word
> slash down to something else.  If I haven't use the single variable "s"
yet,
> and these days I almost never use the old dummies except for screen and
> output stuff of course.... Using the s as the variable holding the "/" or
> the chr("92") works really great because you can cram so much on the line.
> Normally, I wouldn't care, but I've become anal about keeping "spaces"
> between each expression along the line when concatenating things into a
big
> expression.   It just makes it SO much easier for me to read.
> 
> But that is the conflict always coming up with variables.  You can define
> them so clearly using the full 32 characters available to filePro, but
then
> you have to deal with how it fits in use with all the other functions and
> stuff.  Actually, in my playbook, I always opt for really long, very
clear,
> very descriptive variables.  Because years (and evenmonths or weeks for me
> these days) after, the code is SO much more readable.  For example,  would
> you rather see:
> 
> B_a_e_o_y=this + that....
> 
> Or
> 
> Balance_at_end_of_year=this + that
> 
> 
> Sometimes,  saving space is no savings at all.... And if anyone has
actually
> read this far down this message, here is the best filePro tip I can think
of
> bar none.  Do not care about spaces.  FilePro ignores them completely.
You
> gain absolutely nothing by cramming all your code together without them.
> The far better thing to do is adopt a strict format for writing multiple
> commands on a line and stick to it religeously.  It makes it so much
easier
> to search for things, and it is infinitely easier to read.  I have adopted
> putting the semicolon and two spaces without fail before the next command.
> It makes it all so much easier to read than semicolons floating between
> spaces or going one way and then the other  with no regularity.  When I
say
> I follow this strictly.  I would ask anyone to find a piece of code I've
> written any time during the past 5 years that does not have this semicolon
> and two spaces arrangement *everywhere!  I only vary it if there is
> absolutely NO way to fit something on the line that absolutely has to go
on
> that one line.  And then I hate myself for hours.  And Fairlight thinks he
> has OCD?  :-)
> 
> John
> 
> 
> 
> 
> > -----Original Message-----
> > From: Nancy Palmquist [mailto:nlp at vss3.com]
> > Sent: Wednesday, October 28, 2009 1:07 PM
> > To: john at valar.com
> > Cc: 'filePro List'
> > Subject: Re: Cleaning up stuff -
> >
> > John,
> >
> > As always - wonderful information.  I have done just that on occasion
> > but I really like your global rule.   Using a variable
> > instead of typing
> > the \ - will eliminate any issues with the \" or \g or any
> > other thing
> > that filepro understands and reacts to when you do not want it to.
> >
> > That is why I avoid typing the \ whenever I can.  I always
> > get caught by
> > those things, unexpectedly.
> >
> > Nancy
> >
> > John Esak wrote:
> > > In the spirit of Nancy's good suggestion. I'll throw in
> > something.  Let's
> > > see, slashes vs backslashes.
> > >
> > > There is a simple rule regarding the "cmd" functioning and
> > slashes versus
> > > backslashes... But if you don't want to remember when you
> > can and can't use
> > > one or the other, you can do something like this. I put a
> > couple lines in
> > > the global setup of every processing table I write. (You
> > may remember a few
> > > years ago I told Bob Stockler that I had made an
> > unbreakable promise to
> > > myself to write every single table I write to be compatible
> > on either *nix
> > > or Windows. It has greatly uncomplicated my programming life.)
> > >
> > >
> > >      if: @os ne "DOS"
> > >    then: declare global slash(1,,g), nul(10,,g);  slash="/";
> > > nul="/dev/null"
> > >      if: @os eq "DOS"
> > >    then: slash=chr("92");  nul="NUL"
> > >
> > >
> > > Then anywhere after these two lines have been encountered,
> > you can/must use
> > > the variable slash for building any paths.  And you can use
> > the variable nul
> > > to redirect any output when you want it sent to the bit
> > bucket.  So you can
> > > do:
> > >
> > >     then: declare SysCmd;  SysCmd="copy /Y" < path-to-dir { slash {
> > > name-of-file < "2>" { nul { ""
> > >     then: system SysCmd
> > >
> > > You can extend the use of the slash all over, using one
> > variable to build
> > > another. Like:
> > >
> > >     then: declare fp_stuff(128,,g), cur_fpdir(128,,g),
> > cur_fpprog(128,,g),
> > > path-to-map, name-of-fpfile
> > >     then: fp_stuff=getenv("PFDATA") { slash getenv("PFDIR") { ""
> > >     then: cur_fpdir=fp_stuff { slash { "filepro" { ""
> > >     then: cur _fpprog=fp_stuff { slash { "fp" { ""
> > >     then: path-to_map=cur_fpdir { slash { name-of-fpfile {
> > "map" { ""
> > >
> > > Anyway, you get the point.
> > >
> > > Why do I always put a { "" at the end of building any
> > expression?  Just
> > > because.  :-)  Just because it has saved me untold hassle
> > the few times when
> > > it is absolutely required and I haven't got it. Take my
> > word for it, this is
> > > a good tip, and really can never hurt anything.
> > >
> > > John
> > >
> > > P.S. - Maybe Ken will chime in with the simple rule about
> > when filePro
> > > requires a slash versus backslash and really how that is
> > related to the
> > > "cmd" shell interpreter. On *nix, I just use "/" entirely.
> > >
> > > I've left the following because I think you'll all get a
> > kick out of it....
> > > This is what I see after I lapse off into a dead sleep or
> > senior moment for
> > > a moment.... I get all d's or s's :-).  Very embarassing
> > when someone walks
> > > in your office and says "Hey John are you sleeping and you
> > say, "No, why do
> > > you ask?". They point to your screen and walk out of the
> > room chuckling. :-)
> > > )
> > >
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > >
> >
> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
> > dddddddddddddd
> > > dddddddd
> > >
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > >> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> > >>
> > > m] On Behalf Of Nancy Palmquist
> > >
> > >> Sent: Wednesday, October 28, 2009 9:51 AM
> > >> To: 'filePro List'
> > >> Subject: Re: Cleaning up stuff -
> > >>
> > >> Ryan Powers wrote:
> > >>
> > >>>> I can clean out the files but
> > >>>> system "rmdir P:\PCL\20091027" will not work.
> > >>>>
> > >>>>
> > >>> You could try "rmdir /q/s P:\PCL\20091027". The "q" will skip the
> > >>> confirmation prompt. It's identical to 'nix "rm -rf somedir".
> > >>>
> > >>>
> > >> Ryan and Ken gave me great ideas.
> > >>
> > >> I added the pause Ken suggested and the /q/s that Ryan suggested.
> > >>
> > >> I discovered that my pathname in this command needed to have
> > >> the slashes
> > >> flipped.  In my experience, many commands do not care if the
> > >> forward or
> > >> back slash are used, but this one did.  I usually use the
> > backslashes
> > >> for all windows stuff, but did not bother flipping them on
> > >> this process,
> > >> since everything else had worked without backslashes.
> > >>
> > >> Thanks, once again for the help.
> > >>
> > >> I guess I better be more careful of the backslashes.
> > >>
> > >> Nancy
> > >>
> > >> --
> > >> Nancy Palmquist 		MOS & filePro Training Available
> > >> Virtual Software Systems	Web Based Training and Consulting
> > >> PHONE: (412) 835-9417		   Web site:
> > http://www.vss3.com
> > >>
> > >> _______________________________________________
> > >> Filepro-list mailing list
> > >> Filepro-list at lists.celestial.com
> > >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >>
> > >>
> > >
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> > >
> >
> >
> > --
> > Nancy Palmquist 		MOS & filePro Training Available
> > Virtual Software Systems	Web Based Training and Consulting
> > PHONE: (412) 835-9417		   Web site:  http://www.vss3.com
> >
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list

More information about the Filepro-list mailing list