Re: Splitting packages in per-procedure separate files

[Stephen Leake <stephen_leake@stephe-leake.org>]

Francesco Bochicchio <bockman@virgilio.it> writes:

> What I have is an application consisting of a dozen different
> packages. Now the standard mandates:
>
> - one name_package.ads for package public declarations
> - one name_package.adb for package private declarations (including
> separate declarations for all procedures)
> - one name_package-name_procedure.adb for each procedure in the package
>
> Some of the coders have actually followed the standards, some have not,
> putting all the procedure code inside the name_package.adb file. Now I
> have to split these files ( about half of the packages, so probably 10000
> line of codes, not the 20000 initially stated ).

In general, I approve of organizations enforcing coding standards;
they increase overall productivity. 

However, in this situation it's appropriate to consider whether this
coding standard should be changed instead.

If the process you are supposed to be using doesn't actually increase
productivity, or your bottom line, you should change the process in a
way that does. That is _required_ by CMMI, and definitely in the
spirit of ISO 9001.

What is the rationale for putting _every_ procedure in a separate
file?

Why do some coders choose to not follow the standard?

I have very few separate procedures in my applications. I had more in
Ada 83 code, but child packages are in general a better solution to
organizing code.

-- 
-- Stephe