Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Dylan Bridgman:
Writing highly readable code
Jul 30, 2015 @ 12:29:55

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

  • the overall style of the code
  • the structure of the application (directories, libraries used, etc)
  • naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

tagged: write readable code tips style structure naming convention comments

Link: https://medium.com/@dylanbr/writing-highly-readable-code-94da94d5d636

Rob Allen:
Checking your code for PSR-2
Jul 28, 2015 @ 08:17:20

Rob Allen has posted a guide showing you how to make your code PSR-2 compliant with the help of some handy tools, both in and out of your editor/IDE.

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.

He looks at three different methods - not the only ones out there but three quick to implement ones:

  • Using the PSR-2 sniffs for PHP_CodeSniffer
  • Automating the checks with Phing
  • Editor integration (he shows VIM and Sublime Text)

There's links to the tools mentioned here and screenshots/configuration information showing how to get it set up too.

tagged: psr2 code style check phpcodesniffer phing editor vim sublimetext

Link: http://akrabat.com/checking-your-code-for-psr-2/

/Dev/Hell Podcast:
Episode 39: Animal Style
Feb 24, 2014 @ 10:22:39

The latest episode of the /Dev/Hell podcast, hosted by PHP community members Ed Finkler and Chris Hartjes, has been released - Episode 39: "Animal Style".

This was recorded the night before SkiPHP started, which was an awesome PHP conference in Salt Lake City. We ramble about a lot of stuff, including our first conferences, America’s first serial killer, our approaches for giving talks, and Chris’ secret identity.

You can check out this latest episode either through the in-page player or by downloading the mp3 directly. If you like what you hear, consider subscribing to their feed to get this and future episodes.

tagged: devhell podcast ep39 animal style chrishartjes edfinkler

Link: http://devhell.info/post/2014-02-20/animal-style/

Smashing Magazine:
Why Coding Style Matters
Oct 26, 2012 @ 09:41:32

On the Smashing Magazine site there's a new article talking about coding style matters with developing projects with multiple people (or even possible contributors in the future) involved.

Coding style is how your code looks, plain and simple. And by “your,” I actually mean you, the person who is reading this article. Coding style is extremely personal and everyone has their own preferred style. You can discover your own personal style by looking back over code that you’ve written when you didn’t have a style guide to adhere to. Everyone has their own style because of the way they learned to code.

They talk about how everyone has their own personal "style" to their code and how, when working with a team, everyone needs to communicate and make sure their styles match. They also make a few recommendations for your code like leaving "clues" (comments) and making errors easier to spot. There's also a few links to tools that can help keep your code standardized including CSS Lint and the Eclipse code formatter. PHP, of course, has its own - PHP_CodeSniffer with its own rules.

tagged: code style standard communication tools


Volker Dusch:
Errors will be fixed. Warnings will be 'looked at'
Oct 04, 2012 @ 08:25:43

In a new post to his site Volker Dusch shares his thoughts about warnings in coding style checks (and how they differ from real errors).

When it comes to coding standards there is one rule that always makes me cringe when I stumble upon it: "Lines SHOULD be less than 120 chars long. If not a warning will be issued." Let me try to make a point why I consider WARNINGS in coding guideline checks hurtful.

He defines a warning first, so there's no confusion (something that should be done, but doesn't have to) and why he thinks there's not much of a place for them in the code guidelines. He suggests that, by having them, they take away time from the real issues, the errors. He notes that "should" rules on formatting shouldn't be added to your QA tools right away. Adding too many of these that spit out too many warnings (not errors) could just muddy the waters and make the developers more confused.

tagged: errors warnings qa code style guidelines opinion


Dean Clatworthy:
Theming/styling error messages in Symfony 2
Aug 30, 2012 @ 11:40:40

For the Symfony2 users out there, Dean Clatworthy has a handy tip to help you customize the output of your application a bit more - a method for styling the error messages coming from forms using a custom template.

I spent a large portion of my day today trying to customize the HTML produced by Symfony 2 for form errors. The documentation has a section on how to do this, but for the life of me, I could not make it work. Here is a working, re-usable solution.

His solution involves the creation of a template in your "/Resources/views/Form/" directory that contains a Twig template for the error set output. This is then applied in your view using an additional parameter on the error output tag, including this new template from the "Form" directory. This sort of styling could also be applied if you needed custom elements with their own layouts in your forms as well.

tagged: symfony2 error message theme style twig template tutorial


Bertrand Mansion's Blog:
Twitter Bootstrap and the QuickForm2 Callback Renderer
Sep 26, 2011 @ 12:23:41

In a new post Bertrand Mansion shows how he combined the versatility of the PEAR QuickForm2 package and the Bootstrap project from Twitter to quickly make a form using the project's styling (CSS).

I don't know about you, but for me building HTML Forms and styling HTML Forms are maybe the most boring things in web development. It's repetitive and takes a lot of time to do things correctly. That's why tools like Twitter's Bootstrap and PEAR's HTML_QuickForm2 can help with this part of our job. Wouldn't it be nice to have QuickForm2 generate a markup compatible with Bootstrap CSS, so that you could get a nice looking form without to much efforts? Well, that's what I plan to do here.

He starts by creating a simple QuickForm2 form with no renderers attached (no pre-defined styles) and a custom render callback that wraps the items in "div" tags with the correct styles. There's also a custom renderer included for grouping items with additional styling attached.

tagged: twitter bootstrap pear quickform2 callback style render css


John Congdon's Blog:
PHP User Groups (Orlando and Daytona Beach)
Apr 14, 2011 @ 10:36:33

In this recent post to his blog John Congdon looks at some of his local user groups - Orlando and Daytona Beach in Florida - and how they handle their meetings and groups differently.

I am a member of two PHP user groups. Each one runs a little bit differently. I am looking for feedback from other people in other PHP user groups to find ways we may be able to make these better. he East Central Florida PHP User Group (Daytona Beach area) is new/restarting. [...] They seem to be more geared towards teaching new PHP developers. [...] The Orlando PHP User Group is quite different. They lean towards more presentation style meetings. Someone proposes a topic, and then someone volunteers to be the presenter.

He asks for comments from the community as a whole, wondering what he can do and what other groups in similar situations have done to help grow and improve their group. Comments on the post include suggestions of a more traditional approach over the mentoring aspect, a possible mixing of the styles and using tools likee Google Moderator to pick out the topics people are most interested in.

tagged: usergroup opinion recommendation presentation mentor meeting style


Derek Allard's Blog:
Modifying the default CodeIgniter Calendar template for fun and profit
Dec 24, 2010 @ 11:09:33

Derek Allard has a quick post for the CodeIgniter users out there with some styling you can use on the default CI calendar.

A project I’m working on needs a monthly calendar. Naturally, I’m using CodeIgniter as the base of it. [...] My needs were something more akin to the interface iCal provides; broad, spacious, subtle. Obviously, the default is just an unstyled base that CI provides as a starting grounds. The Calendar library documentation provides some insight into how we can start changing this up.

He talks about the settings he needed to change including the "day_type" setting and template that specifies the CSS classes to use. Add in the CSS and you'll end up with something like this. You can download the example files too.

tagged: default codeigniter framework template css style calendar


Richard Smaizys' Blog:
Improve your code style with simple tips
Dec 03, 2010 @ 12:50:56

Richard Smaizys has a new post to his blog with a few simple tips you can follow to help improve your code's style and readability.

So you have to know and you can not forget that your program (not only websites) is like a living beast with whom many people might work in the future. Your code is like your art piece which sometimes need editing, renewal and etc. You can not just think that you will always be the person who manages everything and supports all the bugs. By understanding this you also agree that the code must be maintainable and readable not only for you after a year or two but to other people that may not be so skilled or advanced and otherwise.

He covers two things in this post (there's this other about brackets) - tabs versus spaces (or hard vs soft tabs) and a bit more on braces, specifically about the same line/next line debate.

Have some code style tips of your own or just want to discuss Richard's suggestions? Leave a comment on the post!

tagged: code style tips suggestions opinion