Posted by Jochem Maas on 02/08/05 16:55

Dan Trainor wrote:
> Hello, all -
>
> Being still fairly new to PHP, I thought I'd ask a few more questions
> and get on to the right track here, developing correct coding habits
> before I start to teah myself incorrect habits.
>
> One of my biggest questions is how to go about writing an application
> that uses a single file, i.e. all my html ACTION='s would go to, pretty
> much, $_SERVER['PHP_SELF'].
>
> From what I understand, I make a flat file (flat, as in, not using OOP
> at this time), and then make one large procedural flow, flipping
> "triggers" at various points to tell the script at which "stage" it's
> at, something like the following:
>
> if ($a = 1) {
> // do first thing
> } elseif ($a = 2) {
> // do second thing
> } elseif ($a = 3) {
> // do final thing
> }
>
> Now, that all makes sense, but I'm wondering if it's the "correct" thing
> to do, or would I be better off swapping out "// do x thing" for a
> require() function to split things up into different files, calling a
> different set appropriate for the "step" that we are on.
>
> This may sound like a silly question, but like I said, I feel that I
> should get myself off on the right foot as I start to do stuff that is
> more infolved.

for a 'newbie' you state a decent 'plan' - thats good. there is nothing
intrinsically wrong with your approach but it may become a bottleneck when
you applications start to grow, that is the main reason for trying to
split code up into modules/files/whatever.

again there is nothing wrong with a purely procedural approach as apposed
to OO. both methods allow you to create spaghetti if you want ;-).

a few tips (maybe):

1. dont let you files get too long - it makes them difficult to read
2. get religious about CS (coding standards), decide upon a CS for yourself
and stick to it - it make code easier to read. http://pear.php.net is a good place
to get ideas on CS
3. focus on readability and maintainability - let speed be a secondary
concern (at least for now)
4. don't get too hung up on webapplication paradigms
(front-controller,MVC,whatever), but look at what other people do also.
(try http://phppatterns.net and http://sitepoint.com for more info on those)
5. take time to think about _your_ application structure, and how you would
logically break it apart.
6. tackle one piece at a time.
7. let others review your code if you can (that's not an invite to post
your complete codebase to the list ;-).
8. if your code works, it works, right? who is to say your way is incorrect.
9. break it down, break it down. keep the bits of code managable.... that one
reason I prefer OO - I find it much easier (& neater) to encapsulate functionality
into a class that a function (or set of functions).
10. nearly all of is personal preference, most of the rest is ReadingTheManual
and being consistent in your coding practices/style (at least within the scope
of a single project - you practices/style will adapt/mutate as time goes by).
11. and the eleventh commandment: COMMENT YOUR CODE (maybe check out phpDocumentor).
I dare you to try for 50%comments/50%code, it does not matter how 'bad' the code is
if its that well commented anyone should be able to maintain/change it - thats
a good thing - especially when the anybody is you 18months from now :-).

>
> Any feedback would be greatly appreciated.
>
> Best Regards
> -Dan Trainor
>

[Back to original message]