Piotr Pasich has shared some thoughts on naming in his latest post to his site today. In it he talks about one of the "hardest things in computer science" (naming things) and makes some recommendations to help you make naming in your code more effective.

Precise names for classes is notoriously difficult. Done right, it makes code more self-documenting and provides a vocabulary for reasoning about code at a higher level of abstraction. There are a couple simple tips&tricks to make the names more readable: do not abbreviate, do not add any extra informations (underscore, type), avoid single letter prefixes, etc etc.

But what if you already know and use those rules and you still want to improve naming in your code? I assume that you care, you’re not selfish and you think about elses when you write the code. You ask one of the most important question to yourself, during architecture implementation – how the fellow sitting next to will behave while reading the code.

He's broken up the remainder of the post into different sections, each with a high level recommendation and some follow up description:

• Ask somebody else
• Does it have a single responsibility you can name?
• Simple Superclass Name
• Qualified Subclass Name
• Adding ‘Interface’ word

He ends with a few names to avoid (like *Manager, *Helper or *Handler) to help prevent ambiguity. He reinforces providing meaning in your naming and making it easier for others to understand what's going on.

Time for a little nostalgia today in this new post from Philip Olson looking back at a brief history of the PHP acronym - where it came from and how it evolved to mean "PHP: Hypertext Preprocessor".

While reminiscing what PHP was like back in the early early years, I stumbled upon a little historical nugget from the old website. Do you know what the acronym PHP stands for? Many of us do, or think we do. [...] But how was the definition chosen? For fun, here's a look back at the official vote that determined this new meaning way back in 1998. It might be worth mentioning that Rasmus, the father of PHP, did not vote for the eventual winner.

He also includes a few "notable quotes that could be taken out of context" from Rasmus Lerdorf concerning his opinions on the matter of the acronym's meaning as well as some other brief notes on the history of PHP and its name change.

Time for a little nostalgia today in this new post from Philip Olson looking back at a brief history of the PHP acronym - where it came from and how it evolved to mean "PHP: Hypertext Preprocessor".

While reminiscing what PHP was like back in the early early years, I stumbled upon a little historical nugget from the old website. Do you know what the acronym PHP stands for? Many of us do, or think we do. [...] But how was the definition chosen? For fun, here's a look back at the official vote that determined this new meaning way back in 1998. It might be worth mentioning that Rasmus, the father of PHP, did not vote for the eventual winner.

He also includes a few "notable quotes that could be taken out of context" from Rasmus Lerdorf concerning his opinions on the matter of the acronym's meaning as well as some other brief notes on the history of PHP and its name change.

In this blog post today, ephemera looks at a few of the common PHP errors those new to the language might encounter and an inerpretation of each.

I'd like to dispell the myth that errors are a bad thing. Errors are not a bad thing. Errors are a good thing! They tell you exactly what to fix, and exactly where to fix it. The only mystery is in actually interpretting the language of the error, which is another skill that beginning coders have yet to master. What does the PHP interpreter really mean when it says "unexpected T_VARIABLE"? What's a T_VARIABLE, anyway?

This document is the first in a series that will attempt to help you decode error messages. This version is aimed at very new programmers, working in PHP.

The remainder of the post looks at four of the common errors that might pop up - "unexpected T_VARIABLE", "Maximum execution time exceeded", "Undefined index", and "Syntax error". Under each, she talks about what they mean and how to catch what they're referring to. There's also an example for each to show what the error-causing code might look like.

In this blog post today, ephemera looks at a few of the common PHP errors those new to the language might encounter and an inerpretation of each.

I'd like to dispell the myth that errors are a bad thing. Errors are not a bad thing. Errors are a good thing! They tell you exactly what to fix, and exactly where to fix it. The only mystery is in actually interpretting the language of the error, which is another skill that beginning coders have yet to master. What does the PHP interpreter really mean when it says "unexpected T_VARIABLE"? What's a T_VARIABLE, anyway?

This document is the first in a series that will attempt to help you decode error messages. This version is aimed at very new programmers, working in PHP.

The remainder of the post looks at four of the common errors that might pop up - "unexpected T_VARIABLE", "Maximum execution time exceeded", "Undefined index", and "Syntax error". Under each, she talks about what they mean and how to catch what they're referring to. There's also an example for each to show what the error-causing code might look like.