Following up on his prior post showing how to convert DocBlock comments to official type hinting, Tomas Votruba has continued the series with a new post showing how to do the same thing but without previously defined DocBlocks.

In previous post we looked at how to migrate from docblocks to type declarations. From @param Type $param to Type $param. Even if it doesn't break code like coding standards do, works with inheritance, localized self and static and propagates types to all child classes, it's still not such a big deal.

But how do you complete type declarations if don't have any docblocks?

After a "gloom and doom" start to the post, he circles back around and shows how PHPStan and Reactor can help with static analysis. After providing several examples of how the refactor should look, he shows how to set up Reactor for both return types and the migration of properties to their correctly typed versions automatically.

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 a post on his site Stefan Koopmanschap suggests something that, while not as commonly done as writing docblocks for the actual code, could help with a better understanding of the application's tests: writing docblocks on tests too.

If you've met me at any time in the previous 20 years and you discussed unit testing with me, chances are pretty big that I'd have told you that your test methods in your unit tests don't really need docblocks, because the test methods would be named in such a way that they were descriptive.

[...] Tests can be hard to real though, especially (but not exclusively) when testing legacy code. You may have lots of mocks to configure, for instance, or you may have several similar tests that are testing specific situations, edge cases or bugs you found along the way that you wanted to test before you them.

[...] Documentation is important. It lowers the bus factor, makes it easier to on-board new developers (or temporary external developers, waves) and makes you think about your own code in a different way. We're (getting?) used to documenting our software, but why not document our tests by giving it a bit more context?

He starts by talking about his process for testing (outline the desired tests then fill them in) and how adding docblocks helped him avoid a "nonsensical" test that wouldn't have provided much value. He then briefly discusses what would be useful to document in the test docblocks and provides some examples to illustrate. Finally he suggests something called "Docblock Driven Testing" where the docblock descriptions help to define what is to be tested and help to make more human-readable sense of what can be tested effectively.

On the CloudWays blog there's a new tutorial posted showing you how to create project documentation with Sami, a tool that takes the DocBlock information already in your code and makes it into something more human-readable.

Developers regularly create large blocks of code that form parts of API’s and other mid to large level projects. While there is a (more or less) agreed upon convention for code writing, every developer has a personal comment and documentation writing standards. Some add small cryptic notes while others attach full-length Google Docs that document the method or class in painful details. This problem becomes very severe when the number of end users increases and there is a need for proper documentation of the project.

[...] DocBlocks are important because they are used by a well known Symfony document generator package called Sami. Very popular in PHP community, Sami also provides the ability to create custom twig templates and work with versioned documentation on GitHub. In this article, I will use Sami and a GitHub project Sync Mysql data with Elasticsearch to automatically generate documentation.

The tutorial then helps you get the Sami package installed via Composer and how to execute it to ensure it's working as expected. Next it points you to a project to clone to help with the MySQL-to-Elasticsearch interface. It then helps with the creation of a configuration file, the results of a build and some additional tips for customizing the configuration for your environment.

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.

On the Acquia blog Adam Weingarten has shared some tips for writing good (and modern) object-oriented code in PHP:

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

His tips touch on things like:

• Using a code structure that can be autoloaded via PSR-4
• Namespacing your classes
• Working with types and type hinting
• Using docblock comments for autocomplete in IDEs

There's also a few other quick topics he finishes the post out with: the lack of enums in PHP, working with associative arrays, no functional overloading and assigning responsibility to classes.

On the SitePoint PHP blog today there's a new tutorial posted that gets into the details on one of the powerful (and most used) components of the Symfony framework, the Router, and how to interact with it via annotations. Symfony's route annotations allow you to define functionality at the controller level or via a YAML configuration file.

When you download the Standard Symfony 2 Distribution, it includes an interesting bundle named SensioFrameworkExtraBundle which implements a lot of great stuff, especially the opportunity to use annotations directly within your controllers. The idea behind this article is not to convice developers to embrace this way of doing, but to point the finger at an alternative method to easily configure controllers. Keep in mind that there is no magic recipe, it depends on what you need in each specific scenario. Symfony 2 implements a strong built-in component to manage all the routes of an application: the Routing Component. Basically, a route maps a URL to a controller action.

His example sets up a simple blog and compares the two ways of configuring the routing: one side putting it all in the YAML configuration and the other in the controller docblocks (annotations) themselves. He adds a base page for showing the listing of posts and a single article route, complete with slugs. He also shows how to add in some additional configuration handling to do things like set default values, making things required and enforcing the HTTP method on the request (GET, POST, PUT, etc)

PHPMaster.com is back with the third part of their series looking at Aspect Oriented Programming with the CodeIgniter framework. (Part 1, Part 2)

In the previous parts of the series we learned about AOP concepts and the need for using AOP in large scale projects and I introduced CodeIgniter’s hooks as a convenient mechanism for creating AOP functionality from scratch. In this part I’ll show you how to use both XML and comment-based techniques to create custom AOP functionality when a dedicated AOP framework is not available.

They start with the XML configuration that defines a few aspects and pointcuts for the application. This is then read in via the "applyBeforeAspects" and the aspects that should be executed first are extracted, loaded and run. Following this, they take the other approach - based on docblock comments - and pull in the comments (the @before and @after tags) and load/execute the aspects that way instead.

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.

On PHPMaster.com today there's a new tutorial showing you how to generate API documentation with the help of the ApiGen documentation tool and some commenting in your code.

If you’re writing undocumented code, you should stop this very moment. I’m serious. Drop everything, save and quit, and focus on improving this essential part of your workflow. [...] ApiGen is a docblock parser like PhpDocumentor. PhpDocumentor has been around for much longer than ApiGen, but unfortunately its development is somewhat stunted and it lacks in terms of modern documentation and examples.

He shares an example class, fully commented to show off the right way to handle the DocBlocks and goes through each of the "@" types and explains what they're for. Also included are the instructions for getting ApiGen installed (via the PEAR installer) and a sample command to generate the docs from the source. You can find out more about ApiGen and some of its other options on it's main site.