* If you have lots of code to commit you can potentially cause the SVN commit process to “hang.”
* You can use CI (continuous integration) to instead check the standards and email out notices to the staff if someone checks in a bad copy of the code.

I do recommend a pre-commit hook that checks to make sure code lints (that is, it compiles) but beyond that, I think the work should be done post-commit. See http://blueparabola.com/blog/subversion-commit-hooks-php for more.

DocBlocks are not, in my opinion, for the person reviewing the code (beyond some basics). They’re for someone looking at the API.

And good point about the public properties versus accessors. That’s my take, too.

/**
* Constructor.
* @param string $username The username of the Twitter user
* @param string $password The password of the Twitter user
* @param string $email Optional email address for testing
* @return void
*/
public function __construct($username, $password, $email = null)
{

I can see it’s a constructor. I can guess what “$username” is because it’s well-named, and I can guess that it’s a string. Ditto all the other args. You could delete the lot without losing any useful information. I think *the* key programming skill is learning to express ideas clearly, simply, and concisely. That means constantly cutting and hacking away at cruft.

Short methods which do just one thing help. If this waas split into a _hasBeenPosted($tweet) and _saveTweet($tweet) (roost?) a comment isn’t needed.

/**
* Check to see if this tweet has already been posted and add it to the DB
* if it has.
* @param string $message The tweet
* @return bool
*/
private function already_tweeted($message) {

Good naming virtually removes the need for comments – also testing. Code is best explained in well-factored unit tests which tell little stories about how classes are used and how they will behave. I think this is where the focus should be when you want to learn (or show) how code works. Comments may get out of step with the code but tests never lie.

Definitely agree that private is evil (open-closed principle).

And always use accessors. I’m a Scot and as we know Scotsmen all wear kilts hoots mon och aye the noo etc etc. For better or worse, it seems there is unending interest in what we wear underneath. Now, if you met me, I’m sure you’d ask politely using my public ear interface. You wouldn’t just hoik up my kilt and have a good old rummage around, leaving me exposed to the inclement Scottish summer.

I sort of feel the same way about direct property access.

Soooo wrong. protected is no more encapsulated than public. Suppose we have a public data member, and we eliminate it. How much code might be broken? All the client code that uses it, which is generally an unknowably large amount. Public data members are thus completely unencapsulated. But suppose we have a protected data member, and we eliminate it. How much code might be broken now? All the derived classes that use it, which is, again, typically an unknowably large amount of code. Once you’ve declared a data member public or protected and clients have started using it, it’s very hard to change anything about that data member.

I also didn’t address making the variables easier to read and understand by just looking at them. I didn’t want to open that can of worms.

Thanks for the suggestion!

Generally, when creating classes in PHP, and using PHP’s OO-goodness, I like (as to PEAR and ZF standards) to name members such as methods and properties with camelCasing. Thus “already_tweeted” would be “alreadyTweeted”.

On the other hand, I like to use under_scored naming for procedural paradigm members: functions and variables, when they are used in a predominantly functional/procedural/imperative environment.