Tabs! A lot of tabs in the right places could really bring a fresh breeze through "stinky" code. This rule is usually taught in the first year of programming, but some of you just feel too lazy to do that (even me, from time to time...). Well if you don't tab it from the beginning, rest assure that you will end up tabbing it when you encounter errors.
Variable names! I just love naming variables!! It's so much fun :) and the more fun is when other people are trying to figure out what the variable is used for and they just imagine possible sources f the name. But when I tell them my idea, it makes sense. Let's say I have a variable that refers to a class. I will name it cls. If it's a searching field, it's scls. If it's the result of a query, it's resCls (see, I also use capital letter when binding words). In one word, it could be confusing… that's why I recommend telling the story of the variable just after naming it. At least then you won't be blamed for being an awful "namer". The most popular options are:
- camelCase: First letter of each word is capitalized, except the first word. (like the resCls mentioned above)
- underscores: Underscores between words, like: mysql_real_escape_string().
Comments! As I mentioned at the point above, you sometimes need to tell the story o a part of your code, or to group sections of code. The best way is using comments that describe steps of the algorithm, variables, functions and others. One day a teacher told me that comments should be 20% of your code lines. Never reached that limit, but, hey!, that's what setting goals means. Still, obvious comments like "class variable refers to the class of the object" are useless. Try not being absurd with too many comments :).
Redundancy! If there are too many lines that appear more than once, ore more than in one page, and then create a function… everyone will be happier. Especially you! If you have the same form repeating itself, then put it in a special page and just include it right where you need it. But when you include it you should really explain what it contains, so that debuggers will know what to expect of it.
Visibility! Don't hide the errors! There is a risky functionality in php that hides any kind of error or warning. It is activated by adding "@" in front of the function name (like @mssql_connect). If you call the function like that and the response is erroneous you will waste a lot of time in order to figure out why the page is being displayed blank.
No scroll! I personally hate scrolling. Especially horizontal scrolling. So if u can move the code to the next line instead of letting the viewer scroll it will make people happy.
Quotes! Brackets! Tags! This section is dedicated to a good friend of mine, that now is a few thousand miles away, and that asked me, whenever she felt the need, what is the safest way to place quotes in php? Well, if we are building up a string, let's say $myString="select * from table"; and we have to add a certain value to it the best way is $myString="select * from table where name=".$value; this will cause an error because the value in SQL must be between small quotes. So the correct way is: $myString="select * from table'".$value."'";
If you are using simple quotes than you can escape them: $myString='select * from table\' '.$value.' \' ';
The main idea is to always match the quotes. If you write the first one, always write the second one too. (Do the same thing with brackets. Not all environments are like netBeans and doesn’t auto complete your second bracket).
This way you will never leave them unpaired, and they will never cause you trouble.
If there is a more weird way of adding quotes and I missed it, post me a message.
Why did I feel the need to write this article? Well, because I once spent two weeks trying to figure out why an open source application was not working. There was little to nothing documentation, and the php pages kept including themselves.. There were no helpful comments, and errors were ignored when calling functions. It was a great waste of time.
