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

Jason McCreary:
Writing Clean Code
Aug 14, 2017 @ 10:42:02

In a new post to his site Jason McCreary makes a case for writing clean code in your development processes. He makes three main suggestions of practices you can integrate into your workflow to help make the code you write cleaner.

I noticed [legacy codebases] all suffer from the same fundamental issue - inconsistency. Often the result of years of code patching, large teams, changing hands, or all of the above.

This creates a problem because we read code far more than we write code. So as I read a new codebase these inconsistencies distract me from the true code. My focus shifts to the mundane of indentation and variable tracking instead of the important business logic.

In my experience, I find I boy scout a new codebase in the same way. Three simple practices to improve the readability of the code.

His three suggestions for improving the overall code quality center around standardized formatting rules, consistent naming practices and avoiding nested code. He uses an example piece of code to help illustrate these recommendations with explanations for each.

tagged: clean code top3 suggestions formatting naming nested

Link: https://jason.pureconcepts.net/2017/08/writing-clean-code/

Laravel News:
In Laravel 5.4 You Can Use Markdown in Your Emails
Dec 14, 2016 @ 10:19:10

As is mentioned in this post on the Laravel News site one of the improvements coming in Laravel v5.4 will be the ability to use Markdown formatting in your emails.

Laravel 5.3 introduced two new features around email, the Mailables and Notifications which allow you to send the same message through email, SMS, and other channels.

Building on top of these improvements, Laravel 5.4 is going to include a brand new Markdown system for creating email templates.

Under the hood, this feature implements the Parsedown parser with its companion, Markdown Extra so you can use tables.

They go on to describe how this feature is integrated with the "components and slots" handling also recently introduced in the framework for things like headers, messages, layouts and tables. Also included is some example code showing how to return the Markdown parsed version of a view, using them in notifications and how to use inline styling.

tagged: laravel markdown email mailable formatting output tutorial v54 framework

Link: https://laravel-news.com/laravel-markdown-emails

Matthieu Napoli:
Approaching coding style rationally
Nov 13, 2015 @ 11:51:07

In a post to his site Matthieu Napoli shares some of his thoughts about "code style rationality" including code formatting in general and some suggestions on one of the harder things in development - naming things.

Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.

If at any point you feel like something “just doesn’t look good”, breath in, breath out, and try it! Nothing beats hands-on experience, not even some random article on the internet.

He looks at a few subjects specifically (there's way too many to cover them all in detail):

  • the use of trailing commas
  • alignment of values in docblock comments
  • keeping docblock comments minimal
  • using the "Interface" suffix
  • using the "Exception" suffix

He ends the post by reminding readers that the point is to think about code style logically and that no rules are written in stone.

tagged: code style formatting rational approach opinion comma docblock interface exception

Link: http://mnapoli.fr/approaching-coding-style-rationally/

NetTuts.com:
PSR-Duh!
Apr 12, 2013 @ 10:46:26

On NetTuts.com today there's a post that talks about applying the PSR formatting to your application's code. If you haven't already read their introduction to the PSRs, it's highly suggested.

In a previous lesson here on Nettuts+, you learn about PSR; however, that article didn’t detail the process of integrating that coding style into your projects. Let’s fix that!

They briefly recap the main two PSRs (PSR-1 and PSR-2, but no mention of PSR-3 the logging interface) and show code examples of them being applied. They also point to the PHP_CodeSniffer tool that you can use to keep your code in the correct structure. Instructions are included to install it specifically for the Sublime Text 2 editor via package control. It's just a command-line tool, though, so it could be integrated with just about any other editor/IDE out there too.

tagged: psr psr1 psr2 apply autoload formatting phpcodesniffer

Link: http://net.tutsplus.com/tutorials/tools-and-tips/psr-duh

Gonzalo Ayuso:
Handling dates with PHP
Oct 02, 2012 @ 08:41:09

In this new post to his site Gonzalo Ayuso introduces you to one of the more powerful parts of the PHP language - the DateTime object.

I’ve seen a lot of newbies (and not newbies) having problems handling dates in PHP (and even with SQL and another languages). When I see someone having problems with dates, I always ask the same question. I type in a text editor “27/11/2012″ and I ask him: What is it? If your answer is “This is a date” you should continue reading the post.

He talks about how the DateTime functionality replaces (much more effectively) some of the older date handling methods in PHP. He includes a few examples comparing it to date and showing how it can be used to compare dates. He includes a "Dummy" class he mocked up to show how you could work with DateTime to get/set formatted dates, set the format to use and get the current format. As always, he also provides tests for the code as well.

This is just the tip of the iceberg as to what DateTime can do, so I'd suggest checking out the manual page for it to see the full list of features.

tagged: datetime date time handling introduction formatting

Link:

Antonin Januska:
How To Write Code Comments Well
Aug 20, 2012 @ 10:17:42

In this new post Antonin Januska shares some reminders about what good code comments should look like - what needs to go in and what needs to stay out (you comment all your code, right?)

Code organization is a huge thing, especially for developers (because they deal with code), and often times it’s a philosophical debate as to how code should be documented, if spaces should be used instead of tabs, what kind of documentation should be used and so on. Yet, what no one brings up is the dire issue of COMMENTING. We can all agree that comments are essential (and sometimes used to build half-ass documentation on big systems) but what no one really mentions is the fact that people are crappy commenters.

There's two topics he touches on that (surprisingly) it's easy for developers to forget when writing their code - "be informative" and "use consistent formatting". A lot of the issues could be helped if developers made more use of DocBlock formatting which many IDEs already have support for.

tagged: code comments opinion docblock formatting informative

Link:

DesignLuv.com:
A style guide for PHP developers
Aug 09, 2010 @ 09:13:08

On DesignLuv.com today they've posted what they call a style guide for PHP developers - some types on writing well-styled, easy to read code.

If you’re a new developer and are trying to hone in on your coding style, maybe try giving the following a go. These are simply some conventional formatting methods that are generally appreciated and supported by PHP developers and will improve the overall readability of your code.

They talk about a few different subjects - variable names, class and method naming, bracket spacing, default arguments, constants, loops and a lot more. It's good to see them including things like commenting and file name suggestions.

tagged: style guide developer formatting suggestion

Link:

Brandon Savage's Blog:
Data Formatting: It IS Our Job
Dec 07, 2009 @ 10:26:27

Brandon Savage has a reminder to all of the developers out there about working with input from your users - the burden is on you to format the data correctly, not them.

The simple answer is that whomever designed the form decided to place the validation of the data, and its massaging into the proper format, onto the end user. But there’s a more complicated issue at hand here: the fact that the developer either felt it wasn’t his responsibility to do the data formatting, or didn’t realize that not everyone would think to [input the data] way he does.

He suggests that it's more out of laziness on the part of the developer to want the user to give them the data in the format they want when, really, the application should take reasonably correct (it has to match the type they're looking for, after all) and massage it to what they need. If it doesn't cooperate after this, only then should they toss an error. His examples touch on phone number and date formatting.

tagged: data formatting opinion

Link:

Dave Marshall's Blog:
Landing a PHP job Part 3: Curriculum Vitae
Dec 16, 2008 @ 09:36:17

Dave Marshall has posted part three of his series looking at how to land that perfect PHP job. In this part he focuses on the resume/curriculum vitae - often times your first impression to a potential employer.

In part two of this series, I discussed the technical know how I think will help get you your next PHP job. This part will discuss writing your Curriculum Vitae(CV, resume, etc.). There are a lot of contrasting opinions on this subject, I’ll make a few points, give you some further reading and you can adapt the opinions in to a top notch CV of your own. I’m no major expert and most of the recruitment I have been involved in has been for trainee developers, but these positions attract a high number of CVs, so I’ve seen a fair few.

He includes a few helpful hints like "Your CV does not get you a job", "Don't stuff your CV with keywords/acronyms" and some tips on formatting and proofreading.

tagged: curriculum vitae resume evolve keywords formatting proofread

Link:

Stoyan Stefanov's Blog:
Fancy Formatting
Dec 21, 2007 @ 12:06:00

Stoyan Stefanov has a fun little post showing an interesting formatting trick to make reading arrays/hashes easier:

Writing readable code means proper indentation. Usually you'd tab (or use 2 or 4 or 3 spaces) after every curly bracket. [...] Same goes when you have a bigger hash/object sort of thing [...] But recently, inspired by Firebug's Net panel way of presenting header information, I tried aligning the keys to the right in addition to aligning the values to the left.

Check out the entry for examples of each of these techniques and see which might fit your programming style the best. Personally, the align right style looks nice but could be more of a pain than it's worth to force my editor into.

tagged: formatting fancy hash object align right` formatting fancy hash object align right`

Link: