Code organization

Code organization

[NiGHTS]

When I programmed in C, code organization was very easy. If my code file became too long and complex, I'd simply create new files and separate out code organized in some way. Then I would #include the C files into my main.

In Ada, I've attempted to build packages so that more code can be distributed into organized categories, but that only gets me so far.

In one instance, I have a package that handles an xhtml object, but it has tons of interface functions and procedures to the object the package encapsulates. In this case I am frustrated by the ever-growing size of this source code. The procedures themselves may be grouped into categories, so it would have been nice to move some of these procedure bodies to other files.

In another instance, I have two nested tasks, and the inner task has a number of local functions and objects it uses. With all this spec stuff living inside the declarative areas deep in the body of my code, I would rather organize them in another file, but I don't want to change my code to work with task access pointers (I've tried this and there were problems, so I've had to keep the code there). In this case, or in any case where there is a declarative region with private scope specs, I wonder if there is any way to move code out of the body and into another file.

Essentially the biggest hindrance is the rules of visibility. A procedure or task created inside the body of another one has full visibility of the variables within its scope. If it were possible to move the code somewhere else, I feel like Ada would complain that it can't see those local variables. And if we go the route of outside procedures being passed tons of "in out" to these local variables, then we'd have to also expose their types which may also have been created within a local scope. Many times we need access to a local procedure, so then I'd have to add an anonymous access procedure as a parameter just so it can work with it. At this point, what would have been a simple little utility procedure call has become a monster of parameters that makes the implementation very difficult to read.

I don't think there is anything I can really do other than find creative ways to create more packages, but doing so many times means writing more code to manage the extra packages, memory access, and visibility contexts.

Any thoughts on this?

Re: Code organization

[Shark8]

On Thursday, September 27, 2018 at 8:24:48 AM UTC-6, NiGHTS wrote:
> 
> Any thoughts on this?

Organizationally, I've been able to leverage SEPARATE and nested packages to a fairly decent effect.

As for the particular problem of the nested-task I don't think that would work, although you /could/ make a generic package off of that internal task, using IN OUT formal parameters for the dependent state you're relying on... though I'm not sure that would make things easier, per se.

Re: Code organization

[Jeffrey R. Carter]

On 09/27/2018 04:24 PM, NiGHTS wrote:
> 
> Any thoughts on this?

In my experience, good code organization is a product of design. High-level 
design identifies high-level S/W entities (usually packages). Next-level design 
identifies next-level S/W entities inside the top-level entities (often private 
child pkgs), and so on.

If you start coding before that, it's difficult to retrofit a good organization 
to the code.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Code organization

[NiGHTS]

On Thursday, September 27, 2018 at 10:43:49 AM UTC-4, Shark8 wrote:
> On Thursday, September 27, 2018 at 8:24:48 AM UTC-6, NiGHTS wrote:
> > 
> > Any thoughts on this?
> 
> Organizationally, I've been able to leverage SEPARATE and nested packages to a fairly decent effect.
> 
> As for the particular problem of the nested-task I don't think that would work, although you /could/ make a generic package off of that internal task, using IN OUT formal parameters for the dependent state you're relying on... though I'm not sure that would make things easier, per se.

I had actually not used "separate" before. I read up on it and it's interesting.

Does this only work on procedures declared in the package spec or can it work for procedures declared in the body of another procedure or task?

Re: Code organization

[NiGHTS]

On Thursday, September 27, 2018 at 10:48:49 AM UTC-4, Jeffrey R. Carter wrote:
> In my experience, good code organization is a product of design. 

I agree with this, and clearly a project that has been spec'd in great detail prior to its development would directly lead to a better organized project.

Then you get into the coding and realize Ada doesn't exactly agree with your organization strategy and imposes some design constraints, particularly with a heavily multi-threaded project. This is kind of how it worked out for me. Once Ada forced me into nesting what would have otherwise been living in other packages, my ambitions for file organization went down the drain. And it didn't help that I was on strict deadline by this point in time.

Re: Code organization

[NiGHTS]

On Thursday, September 27, 2018 at 11:01:11 AM UTC-4, NiGHTS wrote:
> On Thursday, September 27, 2018 at 10:43:49 AM UTC-4, Shark8 wrote:
> > On Thursday, September 27, 2018 at 8:24:48 AM UTC-6, NiGHTS wrote:
> > > 
> > > Any thoughts on this?
> > 
> > Organizationally, I've been able to leverage SEPARATE and nested packages to a fairly decent effect.
> > 
> > As for the particular problem of the nested-task I don't think that would work, although you /could/ make a generic package off of that internal task, using IN OUT formal parameters for the dependent state you're relying on... though I'm not sure that would make things easier, per se.
> 
> I had actually not used "separate" before. I read up on it and it's interesting.
> 
> Does this only work on procedures declared in the package spec or can it work for procedures declared in the body of another procedure or task?

I looked into it further and indeed it seems I can use this for separating code for "subunits". I can definitely use this to my advantage.

Thanks for your feedback.

Re: Code organization

[Jeffrey R. Carter]

On 09/27/2018 05:09 PM, NiGHTS wrote:
> 
> Then you get into the coding and realize Ada doesn't exactly agree with your organization strategy and imposes some design constraints, particularly with a heavily multi-threaded project. This is kind of how it worked out for me. Once Ada forced me into nesting what would have otherwise been living in other packages, my ambitions for file organization went down the drain. And it didn't help that I was on strict deadline by this point in time.

This has not been an issue for me. A basic principle for me is to avoid writing 
executable code for as long as possible (though I write specs as soon as 
possible). On tool I use for this is subunits ("separate"), which you are 
investigating in other posts, so perhaps we reached similar destinations by 
different paths.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Code organization

[Brian Drummond]

On Thu, 27 Sep 2018 07:24:46 -0700, NiGHTS wrote:

> In one instance, I have a package that handles an xhtml object, but it
> has tons of interface functions and procedures to the object the package
> encapsulates. In this case I am frustrated by the ever-growing size of
> this source code. The procedures themselves may be grouped into
> categories, so it would have been nice to move some of these procedure
> bodies to other files.

Child packages may be your friend here - those categories sound a bit 
like child packages. They have some special visibility into the parent 
package that completely separate packages wouldn't.

-- Brian