One thing I remember being pounded into my head is to not create CSS classes after their physical attributes. So, for example, if your error text is red, do not call the class red. Instead, be more descriptive of the content.
The predefined PHP constant DIRECTORY_SEPARATOR is useless.
So, the other day, I saw a horrible thing. I saw two PHP associative arrays that needed to be combined into one, and the worst example of NOT using PHP’s built in functions to combine them. They weren’t using array_merge - instead they were looping through each value.
When working at “the triangle” we used junction points on windows to link to repositories that we needed to run the code base - but weren’t necessary for the project. (see creating junction points on windows with linkd.exe.)
While working on a larger site that I may need to use many external libraries, I realized I need to come up with a better __autoload() function (for example, I think it was DOMPDF that had its own autoload function as well. Last time I used that, I had to hack my own autoload to use their code as well to locate files). I researched into SPL autoload functionality, and I’ve found what I need.
This is more of a proof of concept than anything else - as most of my scripts are ;) But, let’s say you have some files that have css in them, either external stylesheets, internal one with style tags or even style attributes - and you need to update the browser support. Wouldn’t it be great to have a tool that could look through these files and point out that there are incompatibilities?
I hate filling out login forms to discover that half of my password is in the username box. Let’s talk about why - and then a solution.
We’ve all been there before, committing code - and then realizing that it was broken (hrm - our unit test didn’t catch it? or… “what unit test?” if you’re in another environment). Well, there is a solution.