Here are a few coding style guides for those of you on the front lines using SASS:
- SASS-Guidelin.es – an opinionated styleguide for writing sane, maintainable and scalable Sass.
- Bigcommerce SASS Coding Guidelines
- Airbnb CSS / SASS Styleguide
Found this video in Jason Kottke’s blog:
Good advice all around. The best one is from the 93 year old:
Don’t listen to other people’s advice. Nobody knows what the hell they are doing.
Which I’ve heard before in Joe Rogan’s stand up comedy:
You know as much about what life is all about as anybody who’s ever lived ever.
a good programmer knows they have to do terrible things to their code. Do it because if you don’t, I guarantee you other people will, and when they do, they will either walk away or create a support ticket. I’m not sure which is worse.
SQL Style Guide – much needed!
PHP Package Checklist – now if only there was a tool attached to this that could generate the report against the package…
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 – very clean and well organized. This is also useful as a reference of good practices for those who don’t necessarily use Apache.
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.
skipfish – web application security scanner