Tomas Votruba has a new post to his site showing you how you can get typed properties in your code "in a few seconds", a feature coming in the next major version of the language, PHP 7.4.

PHP 5.6 and 7.0 is going to be dangerous since 2019, PHP 7.1 is new baseline and PHP 7.3 is just about to be released in the end of 2018.

Is this the best time to upgrade your code to PHP 7.4?

He starts off by talking about the use of the @var annotation (DocBlock format) and how, while they can be informative, do nothing functionally speaking. He shows how to shift this over to a typed property, forcing the value to be an integer. He also covers current use of "best practices" when it comes to typing properties and how to think about future compatibility. He ends the post with the command you'd need to use - making use of the rector reformatter - to shift all of those @var annotations over to actual typed properties.

In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola Poša. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

The TutsPlus.com site has posted the latest in their "Programming with Yii2" series of tutorials with this new article looking at features for the application useful to build community around the site.

In today's tutorial, I'm going to show you how to extend Yii to easily mimic a site like Reddit with voting, comments, and sharing.

[...] I built some my latest Twitter API episodes on the early version of this platform, following friends on behalf of users and analyzing our followers. The site I described in those, Twixxr, forms the foundation of my Yii customization work.

So adding core functionality like voting, comments and sharing makes so much sense. As you expand your Yii codebase with these kinds of features, building new sites becomes faster, easier and increasingly powerful.

He then spends the rest of the article showing how to use three Yii2 plugins to help provide the community functionality he needed: a voting extension, a plugin for integrating Disquis and a "social extension" for other social plugins and widgets. He shows how to get these extensions installed and what code updates you'll need to make to use them across the application. This also includes screenshots of the results so you can be sure that you're on the right track.

In this post to his site Ignace Nyamagana Butera shares a a helpful thing you can do with the regular expression handling in PHP to help make it a bit more clear: embedded comments.

One of the most challenging aspect of using regular expressions is documenting them. More than often you end up with a complex expression that even you as a creator have a hard time documenting. While reading sitepoint recent article around regular expressions I was intrigued that this article did not feature any tips on how to document them. So let’s take a very complex regular expression and see how we could improve its documentation.

He gives an example of a complex regular expression used to parse a URI into its different parts, including an example URI and the resulting parsed array. He points out that, while the regular expression works fine, it's easy to forget what each part does and as it is quite complex. To help remedy this, he includes an example of a commented regular expression (available since PHP 5.2) where you have two options:

• add in named subpatterns with a special < and > notation
• put in literal comments by breaking up the regex into multiple lines and using the hash (#) to mark of the comment at the end of the line

He includes code examples of both of these, resulting in a much clearer, memorable regular expression where the increased number of lines is a good trade-off for clarity.

The SitePoint PHP blog continues their series creating a simple application based on the 500px service with part two, commenting, upvoting and uploading photos. The 500px service is a photo community for discovering, sharing, buying and selling inspiring photography powered by creative people worldwide.

In the first part of this series we used the API to get the latest photos from 500px and filter through them, and we built a user profile with the list of associated photos. In this part, we are going to give the user the ability to vote, favorite and comment on photos, and finally, we will give the users the ability to upload their own photos.

They start with a look at authentication and authorization handling to make the OAuth-based request to the 500px API. Code is included for the connecting class, including the addition of a logger to make debugging the requests simpler. From there they set up the routes for handling votes on photos (PHP and Javascript) and marking favorite photos. They also include the functionality for adding comments, getting the latest comments and uploading new photos to the service. The final resulting code can be found over on GitHub.

Anthony Ferrara has posted another in his series looking at MVC as a design pattern and as an idea for building web applications. In this latest post he goes on to make a point about MVC, how it relates to architecture and CRUD.

Last week I post a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I'm still working on it. It's a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.

He responds to the comment (essentially that CRUD is a solved problem) and where the need for customizations is needed. He suggests what the real problem is, though: the three classes of developers - CMS users, custom developers and users of both.

Paul Jones has written up a response to Matthew Weier O'Phinney's recent post on shared interfaces and the PHP-FIG. In it he talks about the PHP-FIG group itself and specific references back to the original post.

He mentions the ideas of "new thinking" and the limitations that standardized interfaces might try to impose on an application:

One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land. Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.

Matthew Weier O'Phinney responded with some of his own comments and correcting some of the misinterpretation of his original comments.

In this recent post to his blog Anthony Ferrara looks at commenting in your application's code and how to be effective (and not so effective) when using them.

A few weeks ago I was sparked into a twitter conversation with Larry Garfield (@Crell) about the value of comments in code. [...] A pretty innocuous comment [about code that doesn't have comments] that is quite insightful. [...] That led to an interesting discussion that just couldn't fit on twitter. So let me explain...

He defines what he means by "comments" (DocBlock, general comments and legal information) and what sort of things should be inside of them. He also points out a few things not to do in you comments including being overly descriptive and restating what the code is doing (they should be less about that and more about the "Why"). Of course, there's exceptions and he touches on those briefly to finish out the post.

Gonzalo Ayuso has a new post to his blog looking at a method for injecting dependencies into your application's code based on comments in the PHPDocumentor-formatted comments of your methods.

Last month I attended to Codemotion conference. I was listening to a talk about Java and I saw the “@inject” decorator. I must admit I switched off my mind from the conference and I started to take notes in my notebook. The idea is to implement something similar in PHP. It’s a pity we don’t have real decorators in PHP. I really miss them. We need to use PhpDoc. It’s not the same than real decorators in other programming languages. That’s my prototype. Let’s go.

All of the code you'll need to recreate his solution is included - a sample "User" class that needs a valid PDO object in a private "db" property, a "DocInject" class that parses the comments and, using a new feature of PHP 5.4 (traits), injects the needed functionality into the "User" class and creates/assigns the object.

You can see just the full code in these two gists on Github.

Rafael Dohms has posted a new review of a book that focuses on helping you create better, more readable code - "The Art of Readable Code" (Dustin Boswell, Trevor Foucher, O'Reilly). This is isn't about "pretty code" as much as it is manageable, easy to follow structures and logic flows.

"The Art of Readable Code" was written by Dustin Bowell and Trevor Foucher and basically focuses on concepts and suggestions to make you code not just readable, but comprehendible by other developers, or as the author’s suggest, yourself in six months. Code readability is a topic that I truly believe the PHP community does not focus enough on and i really wanted a look at this book to see what kind of ideas it had and what I could do my best to bring to the attention of other developers.

The book is language-agnostic and provides ideas that developers should keep in mind when doing their development - clear variable names, making comments that make sense, refactoring tips and hints for implementing your ideas in code. He recommends the book to any developer (in any language) to help them make code that will stand the test of time and be easier to manage/understand in the future.