Tag: best practices

PHP tags – once and for all. Yet again.

For those of us who have been using PHP since the early version 3 days and such, here is a modern day refresher for PHP tags:

If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

And from the comment on the same page:

Since PHP 5.4 the inline echo <?= ?> short tags are always enabled regardless of the short_open_tag (php.ini) setting.

For me personally, closing PHP tags are a part of muscle memory.  I’ll have to unlearn that, I guess.  And in regards to the inline echo tags, I was under the impression that they are being phased out together with the other short tags (<? … ?>).  Apparently, I was wrong.  They are here to stay.  Which explains why there are in PSR-1, PSR-2, and in CakePHP 3 (which requires PHP 5.4.16 and fully adopts PSR-2) in particular.

A collection of useful .htaccess snippets

A collection of useful .htaccess snippets – very clean and well organized.  This is also useful as a reference of good practices for those who don’t necessarily use Apache.

HTTP API Design Guide

HTTP API Design Guide

This guide describes a set of HTTP+JSON API design practices, originally extracted from work on the Heroku Platform API.

This guide informs additions to that API and also guides new internal APIs at Heroku. We hope it’s also of interest to API designers outside of Heroku.

Our goals here are consistency and focusing on business logic while avoiding design bikeshedding. We’re looking for a good, consistent, well-documented way to design APIs, not necessarily the only/ideal way.

We assume you’re familiar with the basics of HTTP+JSON APIs and won’t cover all of the fundamentals of those in this guide.

Git branch names support forward slashes

Oh. My. God!  I’ve been using git for years now and I only learned this today – git branch names support forward slashes! How awesome is that?!  You can do things like this:

$ git checkout -b feature/foobar

Grouping branches like this is much easier indeed!

I came across this while reading CakeDC’s CakePHP Plugin Standard.  Searching around to find more details, I see that there are a few potential issues with this naming convention, as tools occasionally break (composer, IDEs, etc).   However, these problems are fixed by tool vendors.  Looking into it even further, I found the following description in the book “Version Control with Git: Powerful tools and techniques for collaborative software development” (Google Books preview):

Dos and Don’ts in Branch Names

Branch names must conform to a few simple rules.

  • You can use the forward slash (/) to create a hierarchical name scheme.  However, the name cannot end with a slash.
  • The name cannot start with a minus sign (-).
  • No slash-separated component can begin with a dot (.).  A branch name such as feature/.new is invalid.
  • The name cannot contain two consecutive dots (..) anywhere.
  • Further, the name cannot contain:
    • Any space or other whitespace character
    • A character that has special meaning to Git, including the tilde (~), caret (^), colon (:), question mark (?), asterisk (*), and open bracket ([).
    • An ASCII control character, which is any byte with a value lower than \040 octal, or the DEL character (\177 octal)

These branch name rules are enforced by the git check-ref-format plumbing command, and they are designed to ensure that each branch name is both easily typed and usable as a filename within the .git directory and scripts.

So, as you can see, you aren’t even limited to the single forward slash. Even things like this work just fine:

$ git checkout -b Leonid/ideas/feature/foobar

But remember, just because you CAN do something, doesn’t necessarily mean you SHOULD.  Have a look at this StackOverflow discussion about git branch naming best practices for more understanding on what you should and shouldn’t do.