Best Coding Practices

zzz

Very basic question. It's probably the opening statement at any coding 101 class, but for those like I that got diplomas in other disciplines, I guess could be a helpful tip.

Lately I noticed that I start writing code and as it gets more complex I keep adding layers within the same document. Is it better to create a number of multiple small includes or pages instead of keeping it all in the same multi-hundred-line page?

I think I know the answer, but would like to hear from someone who does it professionally.

halojoy

Originally posted by zzz
Very basic question.
...
Is it better to create a number of multiple small includes or pages instead of keeping it all in the same multi-hundred-line page?

Here is my personal opinion:
Commonly seen difference between Newbies and Experienced

Takes a lot of practice, knowledge and sense to Keep It Simple. ( also known as KIS )

laserlight

It probably depends on your definition of 'better'. If you're aiming for speed, keeping everything on a single page is better since file I/O is slow. But usually modularisation is desirable, so using includes would be better.

zzz

Yep, that's about me:

They pack one page so full of stuff and functions
that in the end nobody can have any overview of what is happening.
And makes testing and debugging a nightmare.

I've got a page that balooned to nearly 1800 lines long. Fortunatelly when i started on it I desided to keep it as clearly marked as possible and break it on logical steps, but it's a giant nonetheless.

zzz

And yes, currently I am aiming at speed -- it sort of compensates for server slowdowns during peak periods.

Drakla

Put reusable code into separate files. Sometimes you might have a slightly modified custom version usable only on one page. When that happens I leave it in the page and if it's also got HTML in it (getting rarer) I put all functions at the bottom.

Get a variable convention going. I use all lowercase for form variables, camel cased for php variables, and functions are underscore separated.

Look at 'professional' code, too. You'll eventually look back on your old code in almost disgust because your practice has changed. I've adopted lots of the PEAR ways and if I find

for($i=0;$i<30;$i++)

// then I now have to change it to

for ($i = 0; $i < 30; $i++)

You'll soon find readability is a big key. If you look at your code in a week and think "what does that bit do?" then you know it's time to comment, rearrange or put something into a function.

zzz

I used to pinch bytes, prior to discovering PHP. I have come to realization of the importance of spacing and better formatting, not to mention clear commenting.

I still hate to comment where anyone can see it by just viewing the source, though...

laserlight

You should look towards improving any algorithms you use, and optimising your own file I/O and database access. These would speed up your code much more than minor optimisation like this.

zzz

I've discovered a great db class that I've been using ever since. It makes my live a lot easier.

halojoy

Originally posted by zzz
And yes, currently I am aiming at speed -- it sort of compensates for server slowdowns during peak periods.

say you have a page (like 5 k😎 with 5 different forms
but only one is used each time page is loaded

using (if - include) maybe same page can be 1kB
doesn't this page improve speed, as smaller pages loads faster?

Or are those include read in by php anyway, just in case needed?

I think there is a balance somewhere, where you can gain speed by putting all in same page. and where you can not.

laserlight

I used to pinch bytes, prior to discovering PHP.

Removing unneeded whitespace in your code does speed it up (i.e. less for the parser to parse) - but then that's best left to specialised optimisation tools as it would also hurt development, which in turn could lead to problems that end up producing slow or even wrong code.

zzz

Or are those include read in by php anyway, just in case needed?

If your logic is clear there's no need to read includes that aren't relevant to a particular case, I think.