API-Blog

First of all remember you should NEVER EVERY PUT DEBUG OUTPUT ON LIVE SITES. In my time as php developer I came across a couple of NOT-Solutions. They are very funny but you should not use it (even in development) :)

The if($_SESSION['user']=="LAMMO") - method

   if($_SESSION['user'] == "LAMMO") echo $debug;

   // * plz make sure not using any brackets! to get the best lammo result :)

I hide my content in the side something - tactic

   <\?php echo debug("asdf"); \?>

Use the Debug Pixel

intention: don't get indexed by a search engine
implication: everyone can see you're debug output
implementation:

hope you had fun ;)

If someone would ask me, how can I make sure I'm not fired in economy crisis and loose my job as a programmer. I would tell him:

Documentation

• Lie in the comments: You don't have to actively lie, just fail to keep comments as up to date with the code.

• Documentation Gotchas: Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper in the movie Bambi "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired. An anonymous comment that says "This needs to be fixed!" can do wonders, especially if it's not clear what the comment refers to. Keep it vague, and nobody will feel personally criticised.

• Document How Not Why: Document only the details of what a program does, not what it is attempting to accomplish. That way, if there is a bug, the fixer will have no clue what the code should be doing.

Program Design

• Avoid Encapsulation: In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.

• The Magic Of Global Variables: Instead of using exceptions to handle error processing, have your error message routine set a global variable. Then make sure that every long-running loop in the system checks this global flag and terminates if an error occurs. Add another global variable to signal when a user presses the 'reset' button. Of course all the major loops in the system also have to check this second flag. Hide a few loops that don't terminate on demand.

• No Secrets: Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can't very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces.

Nameing

• Use Plural Forms From Other Languages: A VMS script kept track of the "statii" returned from various "Vaxen". Esperanto , Klingon and Hobbitese qualify as languages for these purposes. For pseudo-Esperanto pluraloj, add oj. You will be doing your part toward world peace.

• Names From Other Languages: Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.

Testing

... and the best at the end ... lol!

• Never Test: Never test any code that handles the error cases, machine crashes, or OS glitches. Never check return codes from the OS. That code never gets executed anyway and slows down your test times. Besides, how can you possibly test your code to handle disk errors, file read errors, OS crashes, and all those sorts of events? Why, you would have to either an incredibly unreliable computer or a test scaffold that mimicked such a thing. Modern hardware never fails, and who wants to write code just for testing purposes? It isn't any fun. If users complain, just blame the OS or hardware. They'll never know.

• Never, Ever Do Any Performance Testing: Hey, if it isn't fast enough, just tell the customer to buy a faster machine. If you did do performance testing, you might find a bottleneck, which might lead to algorithm changes, which might lead to a complete redesign of your product. Who wants that? Besides, performance problems that crop up at the customer site mean a free trip for you to some exotic location. Just keep your shots up-to-date and your passport handy.

And if that's not enought try the following link where I took those examples from, thx to Roedy Green and Canadian Mind Products