Writing Maintainable Code

[Chris Muench]

Download program (if you want): http://prdownloads.sourceforge.net/p...2.zip?download

Demo of program: http://phppointofsale.com/PHP_Point_Of_Sale/login.php


I wrote an open source program called PHP Point Of Sale. I wrote this code last year and have done updates along the way. The functionality of the program is great,but the code is hard to maintain and prone to bugs.

I want to do a rewrite but I need some opinions on how to write code that is easy to maintain.

I am not sure if I should program with classes and objects or on even how to approach rewriting it, so their is not so much code to maintain.

Basically here is how my program works.
The program runs on a mysql back-end with tables for customers, items, brands, categories, users, and sales. Currently the database structure is not great, but I know what to do in order to fix it.

Their are 4 parts to the program:
Customers, Items, Sales, and reports

In the Customers and Items module I have files for adding, updating, and deleting info from the customer table in the database.

The sales portion of the program is just to add orders to the sales table. This module also has files for updating, adding, and deleting data from the table.

Reports display sale information with 11 reports to choose from.


But my problem is, how can I somehow cut down on how many files and code I have and make the code easier to maintain. Should I have a file for adding, updating, and deleting data from the program?

What are some strategies you use when planning on how to make code easy to maintain?

Thanks for your suggestions,

Chris Muench

[Weedpacket]

We now have a forum devoted to this sort of thing; moving the thread there now.

[drawmack]

OO is intrinsicly more maintainable then PO code. However, well written PO code is more maintainable then OO code.

I haven't looked at your code yet so what follows is simply info for your digestion:

Limit nesting aids in maintainability - Usually when you nest ifs and loops you are using poor logic. Poor logic is prone to bugs and hard to fix.

Analyse all loops and if statements - You should use the bare minimum of loops and if statements. It will make your code run faster and make it easier to maintain in the long run.

Do not under any circumstances type the same code over and over again. Make it into a function so that if there is a bug you only have to fix it once and you're not chancing the ****roaches around with raid for months.

I'll take a look at your code latter then I'll be able to be more specific.

[Shrike]

I'm an OO noob but here's my suggestion (sorry if you aren't a noob )

Before starting the project identify each piece of functionality and consider making this a class. Also consider where functionality is duplicated and look at making a generic class which can be reused. Once you have your classes identified, look at the project as a whole and see if the class heirarchy falls down anywhere.

I didn't follow this on my last project, I started well with a framework class and a number of library classes, but the actual output classes became a horrible montrous mess of code

I read somewhere that if you are wondering if your classes are too complex then you have missed the point of OO programming. That rung some bells

[Chris Muench]

Thanks, that is a good way to aproach it and I will try to do that tonight. I will see how it turns out!