Re: Best Coding Practice

casey.kirkpatrick_at_gmail.com wrote:
> Rauf Sarwar wrote:
> > casey.kirkpatr..._at_gmail.com wrote:
> > > General "best practice" question here, for an "inherited"
program.
> > >
> > > There is a flat file with 9 different record types (for brevity,
> RT1,
> > > RT2, ... RT9). The file serves as a queue of sorts - its records
> > must
> > > be processed in the order they are received, independent of
record
> > > types. About 40% of the logic for each record type must be done
> for
> > > all record types (that is, 40% of the code that is exectued for
RT1
> > is
> > > also executed for RT2 - RT9); about 20% of the logic overlaps a
> > > fraction of record types (RT2, RT5, and RT6 might require the
same
> > > code); and the remaining 40% of the logic is unique to each
Record
> > > Type.
> > > Most of the logic is brief; however, the code for 2 of the record
> > types
> > > is in excess of 3,000 lines of code.
> > >
> > > The current program reads a line of the file, determines the RT,
> and
> > > simply passes all appropriate fields for that type to the
> appropriate
> > > package (there are, therefore, 10 packages - the master and 9
> > slaves).
> > > Naturally, each slave package has the the full amount of code
> > > (redundancies and all) repeated throughout - any change to any of
> the
> > > shared 40% of logic requires synchronized changes between 9
> different
> > > packages.
> > >
> > > Obviously, this is bad. My question is, what would be the best
way
> > to
> > > restructure to packages?
> > >
> > > My inclination is to have one package, period. Have the driving
> > logic
> > > simply run all records through the "40% universally shared
logic",
> > then
> > > call a sub-procedure for each RT.
> > >
> > > The only downside is that the more complex RT's make this
package,
> > > well, huge (a total of nearly 9,000 lines, even after eliminating
> > > redundant code). This gives me a "bad gut" feeling that I can't
> > quite
> > > put my finger on: the code itself will be as modular as ever; yet
> the
> > > idea of merging 10 manageable packages into 1 bohemoth "feels"
> wrong
> > > (particularly in leu of the possibility that multiple changes to
> > > different RT's might need to be worked concurrently by different
> > > developers).
> > >
> > > My question is - is it valid programming practice to merge the
> > > packages; or should I look for more of a middle-ground solution?
> >
> > Couple of things to keep in mind.
> > 1) Write it once and use it multiple times if you can.
> > 2) Keep it simple and tight.
> >
> > 2nd point is not always acheivable due to the complexities of the
> > application logic so the next best thing is to write your code so
> that
> > if you leave the company for a better offer across the country...
the
> > poor soul who will maintain your code afterwards does not curse you
> > night and day.
> >
> > I would extract the 40% common logic and put it in one
master/utility
> > package. Leave the individual and some overlapping logic in each of
> the
> > nine packages. This way you will remove the redundancy but also
keep
> > the separate packages to easily add any additional logic for each
> > record type in future.
> >
> > Regards
> > /Rauf
>
> Right, right - I guess I didn't express the crux of my question.
This
> application has exactly one logical external interface - a procedure
> which takes a couple of parameters (file location, etc.). No other
> application procedures should be called, except from within the
> application (for instance, no other application would independently
> call the RT1 processing logic). That was my major reasoning for
> wanting all of the code into a single package... so I could "hide"
all
> of the extraneous function/procedure calls, and present a single
> package spec which makes this fact crystal clear.
>
> I realize that all coding involves trade-offs, though. So, is it a
> legitimate trade-off to break a large package into 10 separate
> packages, INCREASING the complexity (or apparent complexity) of the
> application's external interface; in the interest of DECREASING the
> amount of code per file for the application?
>
> In summary, is there a legitimate benefit to one of these two
> approaches?
>
> Package A IS
> Procedure MAIN;
> END A;
>
> Package Body A IS
> Procedure RT1 IS
> Procedure RT1a IS BEGIN ... END RT1a;
> Procedure RT1b IS BEGIN ... END RT1b;
> BEGIN ...
> END RT1;
> Procedure RT2 IS
> Procedure RT2a IS BEGIN ... END RT2a;
> Procedure RT2b IS BEGIN ... END RT2b;
> BEGIN ...
> END RT2;
> ...
> Procedure MAIN IS
> BEGIN
> ...
> END MAIN;
> END A;
>
> (versus)
>
> Package A IS
> Procedure MAIN;
> END A;
>
> Package Body A IS
> Procedure MAIN IS
> BEGIN
> ...
> END MAIN;
> END A;
>
> Package RT1 IS
> Procedure RT1;
> END RT1;
>
> Package Body RT1 IS
> Procedure RT1a IS BEGIN ... END RT1a;
> Procedure RT1b IS BEGIN ... END RT1b;
> Procedure RT1 IS BEGIN ... END RT1;
> END RT1;
>
> Package RT2 IS
> Procedure RT2;
> END RT2;
>
> Package Body RT2 IS
> Procedure RT2a IS BEGIN ... END RT2a;
> Procedure RT2b IS BEGIN ... END RT2b;
> Procedure RT2 IS BEGIN ... END RT2;
> END RT2;
>
> (etc.)

None whatsoever. It's all how you want to maintain your code. I would definitely put all the redundant logic in one place, then you can have different procedures in the same package dealing with different logic... you can even keep the code private. So something like,

Package A
Procedure Main;
End Package A;

Package Body A
Procedure Main;
Procedure Redundant Code;
Procedure RT1;
Procedure RT2;
...
End Package Body A;

The beauty of the Package is that you can keep it all togather or separate it into different packages if the individual logic requires more then one procedure.

Regards
/Rauf Received on Wed Jan 26 2005 - 08:38:18 CST