Splitting Up Code in Big Projects

[Glenn9999]

Obviously the method to use to take code into segments in Delphi (managable code sizes, etc) that is units within Delphi, so I'm not really asking that.

But what I'm going to ask is this: How do you typically manage big projects? Or even a smaller one? Let's say I have a unit whose source file is getting too massive to handle on a human level and I want to split it up into two units and then make that available to any program that calls it? What's the best way to go about that in general?

And specifically with the strong typing exhibited in Delphi, how does someone handle that in a clear and concise way. Let's say the one big unit becomes two units, but there's a type definition there that would apply to both units. Is there an easier/cleaner way to resolve this other than making the type definitions into its own unit, using that unit in the two other units, and then requiring the use of both the main unit (we don't want to break programs too much if we don't have to), and the type unit?

 

[Tilen]

Hi

I used to have all in one unit. When it reached 65535 lines... I couldn't debug it anymore, so I needed to split it to two or more units.

My software:

1. reads and parses data into records
2. various analytical calculations and searches
3. report on results

So, I have main unit with all type definitions and reading and parsing process.
ReportAndPrint unit with only functions and procedures for reporting; XML unit with only XML related objects, UML and other graphical units that just do their own thing. But they all use main type definitions from main unit.

This way all the 'core' of the software, which is reading and parsing the data, is in main unit and all the rest in separate units.

Obviously each unit has a couple of it's own definitions, but only related to their part.

This way it's much clearer code to maintain and browse through.

I hope this is of any help, even though '...so I'm not really asking that...'


Tilen

 

[whosrdaddy]

agreed with Tilen,

I split up my code as much as I can. I always have many custom objects, so each object has its own unit. global types and constants are put into a 'global' unit.

//Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[BillKilgore]

There was a cartoon on the wall of one of the IT shops I worked in. It showed two programmers one of whom was sitting at his workstation. The other was saying as he was going out the door, "Start coding. I'll go find out what they want."

The first two points in the sequence of software production as I was taught are Define then Design. First define exactly, or as close as possible, what the user wants to use the software for. This step is often the most boring, at least for programmers who live to code, but it is really the most important. The best programmers are the ones who are best able to discern what it is that a requester really wants and to provide the best design. The better the design the easier the software is to prepare and the sooner the software is ready to use. An effective design can easily be broken down into Procedure and Function level for completion by the software team. Nothing I've found speeds and streamlines the process more then using Objects. Think of a mason using bricks to build a wall as opposed to daubing on clay.

WhosrDaddy is right when he refers to the assembly of objects that he uses. For many years, going back to Turbo 3.0, I've included in my software a basic unit that contains many of the objects I've found useful. In each project I also include a unit for variables, records, and their initialization and another containing common objects specific to the project itself. Each object should only perform one function (small 'f'), if at all possible, and have a name that indicates, as much as possible, what the function does.
After the project is coded it becomes very hard to reduce large multi-step routines and break them out for easy maintenance. It's always been a lot easier for me to use meta-language on paper for the initial design and corrections rather than a keyboard.

I know all this seems pretty basic and I didn't even mention Classes and Inheritance but I can recall in the '70's and '80's trying to modify 30000 line routines in Cobol or Fortran, no sub-routines, loaded with GoTo's, minimum indentation, and little if any commentary. Those were not the good old days.

I hope this helps you and doesn't sound too preachy. I'm glad to be able, for once, to provide some sort of an answer in place of all the questions I've brought to this Forum.