Interesting that you say prefixing type doesn't hold hold up indefinitely... you have used a rather silly example, if anyone was stupid enough to call something just "box" then they deserve to have issues... Infact the previous examples given above were just another method of type prefixing... However, there is a difference between type prefixing a method name, which I don't do, and type prefixing a variable...

Class box will have some member variables which will be either other custom types or native types... type prefixing will still ALWAYS work... member functions are named for PURPOSE and should not have a type because they logically don't "store" a type they have a return type but that is very different... The variable name should also reflect purpose to some extent and prefixing it with type, which only fails if you can't think of a good type name and that is your fault not the system's fault, is a very valuable tool... you see iNumResults and you can guess, it is an Int and it stores the number of results, presumably from a SQL statement....
some people prefer intNumResults, which is just fine... I use simple prefixed for native types and longer prefixes for custom types, so when I look at boxDisplayFrame I know that it holds a "box" type, which is a custom type and it represents the "display frame"

Camel case is a matter of preference, I find it shortens names since I don't have to have the extra underscores and provides EQUAL readability... the important thing is that you are consistent, then you don't have to remember what you typed... it is second nature...

I hate working on aproject where some items are named like this: program_analysis_results_list
and others like this:
programAnalysisResultsList
then you can't remeber which way was THAT particular one written.... I spend too much time searching for them and writing them down so I don't get them messed up... and I hate wasting that time...

You are right, OOP means that the whole project doesn't need to use ONE way.... which was my WHOLE POINT... this thread began as a discussion of proper coding... and my whole point is that ther RIGHT way of coding is "whatever you feel comfortable with!" Only an seriously anal retentive sphincter would care about enforncing "their" own codign style on everyone else... ;-)

Mmm.. I didn't read your original words clearly with regard to the component internals; seems we agree. It's a point worthy of being re-iterated numerous times though; that it's more important to maintain consistency than conform to someone else's practices.

With type prefixing; the developer at some point has to make a reasoned abstraction of the variable's type description - and that abstraction has to facilitate flexibility; there's no point calling a variable iNum if it might be changed to a long-integer at definition later; and prefixing all long's as 'i' to avoid that problem is obscuring type information informally, that would pertain to lesser readability, even confusion.

That was a somewhat contrived example. In a perfect system; there wouldn't be many names of fully qualified classes sitting around in hard-coded routines; but unplanned systems often start out imperfect =P.

Heres a q about programming standards.

Should i use <?php or <?

<?php because you won't always know if the sever is using apache, and if it has short tags on.

Thanks.

I say, typically, you should use the full standard method of delcaring your PHP code sections as suggested above.
BUT, the following guidelines can help anyone who has this question:
If you plan on sharing code: use the full declaration <?php ... ?>
If you will not share and have total control over the server where it will run: do whatever you like short or long
If you will not share and you DON'T have total control over the server where it will run: use the full declaration <?php ... ?>

So following those guides, only people writing code for an internal prorietary system with full control over server environment should use short tags for declaring php code sections, ALL others should just use the full <?php declaration ;-)

Matt, I agree, the most important thing is being conisistent... cool we agree to agree, new one on me there...

About the variable naming though... This goes back to OOP, if you need to change the implementation, you only have to worry about the effected modules, and since code refactoring is a quite common function in IDEs, it is little effort to keep the prefix in line with the actual type... When I , which rarely happens, need to alter the type of a variable, I refactor the names, for example iNum would become dNum or lNum if I changed it to a double or long respectively...
Code refactoring for these rare cases takes like 3 seconds but the benefits of knowing what you are looking at, at first glance, is priceless... kinda like MasterCard...

So I guess there, we will have to agree to disagree ;-) ... sigh ... that's more like it...

But again I reiterate, I use what I find works best for me, and encourage you to use what works best for you!

Some things in this world are obvious right vs wrong, but so many people feel the need to, I don't know, justify their existance or prop-up their self image by forcing others to agree that, A) there is only 1 way and B) it is their own way that is THE one right way...

I tell these people, if you feel the need to enforce your ideas on others, you are usually wrong...
Sharing ideas, learning what other use, what works and what doesn't (and why) for others is a GREAT thing. I encourage ALL my employees to grow, learn and try new things... We set development standards and rules in our teams by concensus within the team. We make accountability a key aspect with this freedom, if something just isn't working, they are expected to recognize it, document it, and fix it BEFORE it is allowed to get out of hand...
Through this we have developed a set of "best practices" which are our own, what has/hasn't worked for us, why and why not... It helps us do the job better, faster, stronger... like Steve Austin (the 6 Million Dollar Man) not the guy from Bakersfield, California... Bionic Coders' Club ... cool name, but not one we actually use... so that is NOT an advertisment... I wonder if that exists somewhere... any I digress...

So for ALL those out there with questions about coding standards, follow these simple rules...
Be Clear
Be Concise
Be Consistent
Be Flexible
Be Open
and
Think Ahead

Most problems are easier to avoid than to fix!

Does "coding standards" include the structure of your projects file system?
Just want to know what type of file structure you guys go with or if thats not considered a part of the "coding standards".

For big PHP projects i like to make usuallt 5 dirs:

Res (pictures etc)
Lib (#include files)
Upload
Src (Pages)
Dta (Data files)

I would call a file e.g Src_Index.php

Again, I reply with use what works for you, but think it out thoroughly before you being...

A finely tuned file system is AS importantant as a well designed database schema... yet it is where people often go wrong right from the start...

The key is to have a full plan of the final project before you begin. You don't have to know every detail, but you have a firm plan about what will be included and generally how it will work... from this you can design a file system that best meets your requirements.

It is a good idea, as mentioned above to have some centralized locations for non-code files, such as images, flash files, includes, etc.... I have seen projects where they have image subdirectories, for example, in every directory where the pages need images, which is pretty much everywhere, managing these becomes a nightmare, seriously.... CENTRALIZE these sort of resources and your life will be much easier. Besides, it facilitates reuse...

Other than that, I have also worked on projects where ALL code documents were stored in 1 common directory, so there was no depth in the file structure... this had advantages and disadvantages, as does building a files structure that matches your site navigation and/or layout...

That is another option, MANY people promote building file structures that match your site navigation or system layout, or flow... etc. This sounds good at first, but it can lead to serious maintenance costs, especially when making even slight changes to site navigation or design...

I am NOT saying any of these is better or worse than the others, except to say keep the resources centralized, but I want you to understand the various options commonly used and know that it is important to plan this out, don't let yourself be led into building folders ad-hoc (as you need them) if you find this happening, you didn't plan well enough, try better next time ;-)

One other point that everyone should plan at this stage is the linkage of their contents... I mean the actual format the URLs will take... relative vs absolute URLs, etc. when one should be used, when another should be used... each has an advantage, and search engines often use this info to help rank your site...

Absolute links are better when moving the source page within your site but worse when moving the target page within your site. Relative links break either way, so they are always on the worse side... BUT if you have a complex file/folder structure you may have very long, complex absolute URLs and be tempted to swutch to relative...

One work around that I have used, is URL rewriting with mod_rewrite... You can simplify long URLs in a complex folder structure allowing you to keep those long URLs simple enough so you don't get tempted to switch to relative URLs...

Also, take advantage of PHPs enviornment variables to keep absolute URLs easy to write and flexible...

Honestly, I keep most of my code files in a limited number of folders... too few and it is hard to find the right one in a huge list, too many and you get click crazy trying to work with the code.... I try to strike a balance...

Peace,