Re: Using

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