In a new post to their blog, Exakat looks at the use of eval in PHP applications and how, despite all of the warnings against using it, it's still found in quite a few codebases (based on their scans).

It is 2018, and we can still find eval() being used in more than 28% of every PHP code source. It is repeatedly reported as a security issue and a performance bottleneck, and a memory hazard. Yet, we can’t get rid of it.

It seems reasonable to think that most of eval capabilities are available as a PHP features. So, we took examples from 2000 PHP open source projects, and reviewed the situation. Here are real-life examples of eval usage : for each of them, we’ll discuss the actual replacement.

Their examples include the use of eval for:

• JSON decode replacement
• Creating missing classes
• Rewriting classes on the fly
• Code compatibility
• Dynamic variabling

...and several more. Each comes with a summary of the method and code showing how it's being used. While some of the suggested replacements are built-in features of the language, others are recommended packages that can provide the same or similar functionality to what the original author was trying to accomplish.

Christian M. Mackeprang has a recent post to his site sharing a few possibly forgotten code constructs whose use has faded in recent years. He revisits them, complete with code examples, and why he thinks they should be resurrected.

Some things in the programming world are so easy to misuse that most people prefer to never use them at all. These are the programming equivalent of a flamethrower: You might rarely be in the position to really need one, but every once in a while it turns out that you need to take down a forest. In that case, there’s no easier way than going Rambo on your codebase.

[...] That’s where a few of the old, forgotten code constructs come into play. Creative use of features such as goto, multiple inheritance, eval, and recursion may be just the right solution for experienced developers when used in the right situation.

The four constructs he recommends are: goto, multiple inheritance, eval and recursion. For each item in the list he provides a basic look at the concept and follows it up with "the right way" of doing things to prevent common issues with the feature.

In a recent post to his site Tim Cotten talks about how it's possible to screw up singletons in PHP. Singletons are a design pattern that returns the same object once it is created each time the method is called.

“Echo chambers” are an oft-encountered downfall of developers when learning new skills or implementing unfamiliar systems. What begins as a simple question leads to a collection of up-voted knowledge perfectly ready to be copied into your project?—?a great thing for productivity (if you don’t mind getting it wrong).

[...] With that example of echo chambers in mind let’s follow the path of a developer deciding to implement the Singleton pattern in PHP.

He goes through the mindset of a PHP developer wanting to use a singleton in their application, finding an example on the web for their need (making a PDO instance). He gives a sample implementation based on the web examples and tries to execute a test script....with a less than helpful error message. He points out that he's not picking on the source of the example itself, but using it as an example of the "echo chamber" idea perpetuating an example without understanding the logic.

He continues along this same path of thinking with an example from another source - StackOverflow. He cites a specific example, points out the issue and the code it contains. He ends the post with some helpful suggestions on how to "break" this echo chamber and improve the resources in various places on the web.

On the TutsPlus.com site there's a tutorial posted about using PHP CodeSniffer with WordPress, a popular PHP coding standards tool that helps enforce common coding practices and style in your application.

Oftentimes, the way in which we write code depends on how we got started with programming. [...] In this article, we're going to take an introductory look at code smells. We're going to examine what they are, what they look like, and how they often manifest themselves in the work we do. We'll be using PHP for our examples.

They start with an introduction to the topic of "code smells" including a few examples along with matching code snippets:

• Example 1: Clear Naming Conventions
• Example 2: Stay DRY
• Example 3: Long Parameter Lists

They also include some solutions that can help you avoid these "smells" in your code and refactor out ones that might already exist.

In this article on Medium.com Amo Chohan covers some of the changes that are coming to the language in PHP 7.1.

Below are the key changes that will be introduced (or removed) in PHP 7.1. For a full list, and to see which changes are being discussed, check out the official PHP RFC.

Included in the list of updates/additions are things like:

• Catching multiple exception types
• Support class constant visibility
• Void return types
• Warn about invalid strings in arithmetic
• Deprecate and remove mcrypt()

He then goes through some of the complete list and provides a brief overview of the change and some code samples where appropriate.

Jeff Madsen has a quick post to his site showing how to use Faker to populate data in Laravel directly in the framework's generated "seeders".

Hello, Mr. asdfgh qweefg! Welcome to kgjhjgjh! Thank you. Only the name's not "asdfgh qweefg".

Sorry! It's just easier.. You're always showing everyone on Laravel Quick Tips these helpful little tricks. Why not show them how to give me a proper name?

He includes an example of creating a Faker object in the seeder and using it to make name, email, age and city values. Naturally, not everyone's going to have English names or locations, so he shows how to set the language, locale and a few other tips:

• shortcuts for optional data
• randomized email addresses
• random elements from a given set

He also mentions custom providers but points to the Faker documentation for a bit more information about that.

On the Vertabelo blog Patrycja Dybka has put together a side-by-side comparison of Doctrine 2 vs Propel 2, two of the more popular PHP-based ORM tools, largely popular in the Symfony communities.

When you start working with data in an application, you may need to use an object-relational mapper (ORM), a layer between the database and application. For PHP the two most frequently used ORM's are Doctrine and Propel. That's why I decided to compare the main features of Doctrine in version 2.4.7 and Propel in version 2.0.

She doesn't try to pick a "winner" but instead talks about the features of each and the main difference between the two (ActiveRecord vs DataMapper patterns). The remainder of the post is the side-by-side listing of the feature of each including:

• Install method(s)
• Model structure definition types
• Mappings
• Supported databases

There's also some examples in the list of code to define tables, perform basic CRUD (create, read, update & delete) operations, basic queries and custom data types each includes. It's a good comprehensive list if you're trying to make a decision between the two or even just looking to find out what each has to offer.

In this new post to his site Jani Hartikainen suggests a few things you can do to help make your code "self-documenting" and more readable down the line (or for other developers).

Isn’t it fun to find a comment in code that’s completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand? One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn’t need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it’s less likely they’ll be crap! In this article, I will show you several ways you can make your code document itself.

He breaks it up into a few different sections, each with some code examples and descriptions:

• Naming things
• Extract functions
• Introducing variables
• Defining class and module interfaces
• Code grouping

He finishes up with a few smaller tips including "don't use strange tricks" and "use named constants". What do you think makes for good self-documenting code? Share some of your own thoughts on the post.

The PHP-FIG (Framework Interoperability Group) has been helping to define standards that can be adopted by projects to make them easier to cross-pollinate and give developers more choices with less hassle. One of the latest to be proposed by the group is PSR-6, the Caching proposal. For those not familiar with it, Robert Hafner has written up an introduction to the proposal and what it all entails.

There’s been a lot of discussion about PSR-6, the php-fig caching interfaces, so I thought it was time to step in and describe what this system is all about. Be prepared to read far more about caching interfaces than you probably thought possible.

He starts with a look at why a standard like this might be necessary (and links to the PSR-6 docs for the official word). He does also mention some alternative proposals and gets into details - with code examples - of each of them and shows how they relate back to what's proposed in PSR-6. He finishes off the post with a brief Q&A trying to dispel some of the myths that have com up around the standard. These include "This is all just too complex", "The Pool/Item model isn’t used anywhere" and " This is just standardizing Stash", each with their own summary and feedback.

On the PHP Manual Masterpieces site has a recent post looking at PBKDF and PHP (and, more specifically, the information that's presented about it in the manual).

So why are we here? Well, a faithful follower slipped me a tip to check out the documentation. It turned out I agreed: I don’t like it. [...] Let’s be clear: I have read the backing C code of this feature and I see nothing wrong with the actual functionality. My issues are strictly with the documentation and the API, both of which are very PHP-ish in the sorts of ways that drive me to hateblog about a programming language on a Friday night. It turns out there are people who are totally okay with these design decisions, and I can’t help that their subjective tastes are wrong, but that’s just how it is.

She mentions three different major issues with the documentation currently in the manual:

• Non-copypaste-safe cryptography
• The fact that PHP does not fail effectively when it comes to cryptographic handling
• The lack of units defined (like for the "length" parameter of hash_pbkdf2)