I've spent the last 2 weeks programming my iPhone app and now it's over I'm back to my regular language, a 4GL procedural language.

God it's awful!

It doesn't help that it has been written with no comments but I'm trying to "repair" one report and so far it has taken me into 4 different files and I still haven't found anything relevant to the actual report!?

It's absolutely awful.

Having done a bit of the iPhone stuff I'm beginning to see where OO principles can be used in our code.

Good move.

Make that 8 files of unintelligible code and still no relevant code found.

I got to my 10th file and gave up.

I've added a development job for the report to be rewritten from scratch.

It's getting on to being 17 years old so could probably do with being updated

Good move.

I've been looking through a couple of python files over the last few days, one is over 3000 lines long and has very few comments...I know nothing about Python so it's really hard going...

Following on from the fact that I've had a few of these occurrences where I have had to give up trying with code because I just couldn't understand it I have started to come up with some sort of model that I can sell to the rest of the dev team.

None of them are OO programmers so training would be in order and we're still quite a way off but I think I've found an "in".

Whenever reports are run they are sent to a queue that then sends them off one at a time. Each item in the queue has a program name that is the starting procedure file for the report. The file is then run with a load of parameters (normally in the form of a record or comma separated string). The reports then seem to span several files with shared variables accessed in all the files and parameters passed to different procedures and branches where depending on various values there will be a different file out of a selection of 2, 3 or more...

etc...

Then once the procedure is done it outputs it (long hand) i.e. writing the output procedurally into a temp file that is then either printed or emailed or saved to PDF or whatever.

The language I use has other files called "include" files. When these are pointed to like this - {includefilename.i} then everything in the include file is copied at compile time into the file and compiled into a single binary file. i.e. if you change an include file you have to recompile every file that contains it.

For each item report, customer report, revenue report, supplier report, etc... the whole process is repeated and files of code have to be written. If it has been done well then reports can share files but this rarely happens as all the files are named thusly... "p42r199b.p", "srspr21.p" (those are 2 examples of actual file names in our code) so there is no way to tell easily what they do and so code reuse is very low.

My model is thus...

Class 1. XMLDocument (XML/SAX writer wrapper class). This contains a reference to a string (or some more suitable object) containing XML code. It also contains several methods that point to our SAX writer which is used to add elements and formatting to this XML code.

Abstract Class 1. Communications. This contains methods for emailing, printing, saving to file, saving to PDF, etc...

Class 2. Report. This contains an XMLDocument object and implements Communications.

Class 3. ItemStockReport. This is a child of Report (i.e. it extends it in Java speak). The only method (or one of only a few) is one that iterates through the data and adding elements and formatting to its XMLDocument. i.e. go through each depot and add the depot as an element to the XML document. Now go through each item in the depot and add elements to the XML document for the quantities the depot has.

Class 4. CustomerSpendReport. This is also a child of Report. Its method will go through the customer table and add info to its XMLDocument about what the customer has spent in the last year.

Now to run a report.

You add a report request to the queue and the request will say something like "ItemReport with such and such parameters" or whatever. This then instantiates the report (which triggers its main method) and then decides whether to print or email etc... the report.

If at any time we then change the SAX writer we use to a new, faster one then we can rewrite XMLDocument for the new writer. No recompiling of anything other than XMLDocument.

If we change our email server and we need to change the settings for sending emails then we rewrite the Communications class and anything that sends out emails changes to use the new server.

I think the dev team will like this. So far I have struggled to come up with ideas for OO stuff and they've always said "Yeah, but we can already do that", etc... but I think this will work.