Re: Best Coding Practice

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 Received on Tue Jan 25 2005 - 18:11:32 CST