Re: modular programming

Dear Steven and Kunal, Agreed with what you had to say. > In my experience, 'modular coding' is entirely a process of evolution. > It's impossible to sit down and design software on paper. Every piece of > code I write is under constant evaluation. Each time a weakness is > exposed, I rethink my strategy. Often there is no 'perfect' solution, > since each presents a different set of compromises. Devoting yourself to > endlessly rewriting and structuring your code will, in the long term, > yield better code than anyone can advise in a book or paper. This para gives an impression that modular programming is an iterative process (maybe not Steven's intention). An iterative approach would certainly enable you to improve the quality of your code - at some expense to rethink/re-implement, and such improvements may well occur through changes to the modularisation/interfaces between modules. Modular programming as a philosophy though, starts at the program design stage, not at version two! 'Modular programming' as a concept is quite old (in computer/doggie years). Then there was the whole confusion/absortption/improvement of philosoophies into 'structured programming' - which some will argue is the same and others maintain a difference (I... - who cares!?). The real 'excitement' was stirred up by a paper (which became very famous) called 'GOTO statement considered harmful' and a massive debate erupted as to whether one could write programs without using GOTOs - is there a GOTO command in PHP? The guru at the time was "Jackson", and if you plug "Jackson structured programming" into Google (or your favorite SE) you will be inundated with 'stuff'. He wrote a fairly thin and most readable book on the subject, but I doubt it is still in print (check Amazon etc). In those days it was also known as JSP. Unfortunately that acronym has been also taken for something else more recently. The design process, and if you want them, the pretty diagrams, have been refined and 'improved' over the years, so there's plenty of material about. Most likely it is built into every 'introduction to programming' text (that is, programming as a process, not learning a specific language!) These days of course, much of the philosophy of splitting up a monolithic program into a series of smaller, inter-communicating modules has been absorbed into the object-oriented approach (and various other 'bits' grafted on to make it bigger, brighter, and better - as they have become implemented (and made practical to use) in various programming languages/systems). Unfortunately PHP is designed to output HTML and that is a very procedural process, so PHP has limited OO facilities. Reading up about classes and encapsulation will pretty much take you through modular/structured design theory and if you use other 'modern' (programming) languages then that might be a good move for you (us 'old dogs' can handle the concepts, but seem to have fundamental difficulties with the mechanics of the 'new tricks'). Which brings us back to Steven's third point - that such things can be overdone. Structure (of whichever flavor) is designed to make the coding/debugging/come back and extend/'improve' it later, processes of development more efficient. This is quite separate from execution efficiency. However there is no way one can improve one, and neglect the other - nor should vice-versa be allowed to become an excuse for slapdash coding practices! Some people associate the word 'module' with (in PHP) 'function'. So they think of modular programming as a code that is divided up into a series of subroutines, ie functions/calls. This is overly simplistic. Each WHILE loop (for example) is also a 'module'. It has a particular purpose, contains a set/module of functionality, and has definable beginning and end-points/conditions. Deciding how to best structure your code to suit the process is a question that appears here quite often - how often are we asked something like: 'I have a database listing a series of ... and I want to copy these out to an HTML table with n-columns across the screen' and the neophyte coder is quite confused and wants to know how to handle the (exceptions of) situation? The problem is one of 'structure': the database yields a one-dimensional list of 'whatevers', but the output screen is a table divided into n-columns - and worse, the complication is (handling the exception conditions, for example) that we don't know if the number of db-rows divides evenly between the number of screen-columns. So most start coding and take their 'structure' from the database call, ie a list, and then try to 'share out' the rows across the screen - and get into trouble when it doesn't all fit together neatly (without 'exceptions'). Structured programming suggests that one examines (diagramming) the structure of the input and compare that with the structure of the output format. These two structures should then be 'aligned'. In doing this it comes down to a choice: do I take the list and split it up into m number of table rows, n-pieces/columns at a time (and handle non-uniformity at the end); or do I output all the HTML for a column, within a row, within a table - and when I need it, call for the next db-row data from the source db (if there is any). So when you look at 'structured programming' you can see that it has more to do with 'data' than with code - at first. When you get to the code, you will see that the structure of the code looks somewhat like the structure of the data - and that the way to process splits up quite 'naturally' into 'modules', ie HTML table processing begins on line X1 and proceeds to line Y1, within that row processing is between lines X2 and Y2, and within that item/column processing fits between X3 and Y3 - and finding the input data from the database is handled in a procedure off to this side, which in turn grabs data from a resultset that was retrieved from the DB by function ABC... Reading other people's code is a good idea to learn about techniques and the programming language. However, as a means of absorbing style and design decisions the maxim most often heard is 'do as I say, not as I do'! So I recommend a bit of background reading and then 'finding your own way/style' as you gather experience/fit in with corporate requirements. Regards, =dn