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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
