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



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to