In a new post to his site Tomas Votruba takes the opposite approach to writing good code by sharing bad examples in the form of fourteen tips to write bad code, practices that can make code hard to upgrade and difficult to maintain.

Today I'll show you how to own your company. All you need to do is write code that no-one can read, is hard to refactor and creates technical debt. It's not easy, because if other programmers spot you're writing legacy code, you're busted.

If you keep a low profile of very smart architect and do it right, you'll be the only one in the company who knows what is going on and you'll have a value of gold. Learn how to be successful living vendor lock!

He then goes through his list of poor practices to avoid including:

• Use protected instead of private
• Use Non-String Method Names
• Don't Always use PSR-4
• Hide Your Dependencies in Constructor
• Use Annotations to Define Magic Methods
• Use Traits with Annotations to Define Magic Methods
• Use as Short Naming as Possible

...and many more. For each item in the list sample code is provided so you'll know exactly what to avoid.

The Laravel News site has a new post sharing the application of "clean code" concepts to PHP with a few handy examples. These suggestions are pulled from this set of guidelines.

Clean Code PHP (jupeter/clean-code-php), is a guide based on the book Clean Code: A Handbook of Agile Software Craftmanship, a classic programming book about writing maintainable code by Uncle Bob Martin.

The clean-code-php guide is inspired by a JavaScript adaptation, clean-code-javascript with PHP-specific features.

Examples they show in the post are around unneeded context, the number of function arguments and functions doing more than one thing. They also include a word of warning about these and other "clean code" suggestions, pointing out that they're mostly matters of opinion and not hard and fast rules to enforce every time. The post ends with links to two "clean code" resources for more reading: "[Clean Code]"(https://amzn.to/2wFCjo4) and "The Clean Coder: A Code of Conduct for Professional Programmers".

On the SitePoint PHP blog there's a new post from author Shahroze Nawaz that shares the results of a survey performed with several "prominent PHP community members" about their usual development workflows.

Workflow refers to both the process and the tools that are used in this process. Almost every developer comes up with a process of creating and finalizing the project deliverables. This process is implemented through a set of tools that the developer comes up with through trial and error. Once a workflow has been perfected, developers follow the process almost religiously because of a simple reason: following workflows reduces most of the management problems that developers have to face during a project.

[...] Here are some of the PHP ecosystem’s most popular developers and designers, and their tools and/or workflows. Note that these workflows will by no means be comprehensive, but even mentions of tools used by some of the more prominent members of our community should be enough to warrant checking them out.

PHP community members on the list include:

• Taylor Otwell
• Phil Sturgeon
• Nicolas Grekas
• Manuel Lemos
• Josh Lockhart
• Cal Evans
• Kat Zien
• Laura Elizabeth

Each person on the list describes their tools of choice for both development related tasks and how they keep organized. There's plenty of links to these tools and services too for you to check them out on your own.

The SitePoint PHP blog has a new tutorial posted that introduces the idea of "Poka Yoke" - basically defensive programming - and how to apply it in your own development processes.

When working in a medium to large team on the same codebase, it can sometimes become hard to understand each other’s code and how to use it. [...] It can be quite hard to remember how particular classes were intended to work, both on their own and in combination with each other. At that point, it becomes easy to accidentally introduce side effects or bugs without realizing it.

These mistakes might get caught in quality assurance, but there’s a realistic chance they might slip through. And even if they get caught, it can take a lot of time to send the code back and get it fixed. So how can we prevent this? Enter “Poka Yoke”.

The article then introduces the basic ideas of "poka yoke" and the two main parts: mistake prevention and mistake detection. It then gets more practical and suggests some PHP-specific things that can be done to prevent mistakes such as:

• the use of type declarations
• using value objects
• making use of effective validation
• returning null objects

For each there's a brief explaination and some sample code to help make the example more practical.

The Tech Beacon site has posted a list of thirty-five programming habits that make your code "smell", little things that you might do every day without knowing they could be causing issues with the long term maintenance of your code.

Bad habits are hard to break and even harder if you don't realize that what you're doing is undermining your work. If you know but don't care—that would be the worst. But you're here, aren't you?

As a programmer, I've seen a lot of poor practices, not just around code, but also around teamwork skills. I've been guilty of practicing many of these bad habits myself. Here are my top 35 bad programming habits, organized into four categories: code organization, teamwork, writing code, and testing and maintenance.

They've broken up the bad habits into different categories to make it a bit easier to consume:

• Code organization
• Teamwork
• Writing code
• Testing and maintenance

I think just about any developer out there as, at one time or another, fallen into the trap of one or more of these bad habits.

On the DaedTech blog Erik Dietrich has written up a list of a few things he suggests avoiding when using logging functionality in your application. The suggestions range from the actual contents of the message out to some logging best practices.

It seems almost strange to talk about avoiding things while logging. After all, logging is your last line of defense or your salvation in many cases. [...] Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems. You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it. You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them? Let’s take a look at some things that can come back to bite you.

He points out the following (common) bad practices he has seen during his time developing:

• Forgetting Context
• Cryptic Codes
• Spamming the Log File
• Unsafe Logging Calls
• Mixing Application Logic with Logging

He ends the post with a suggestion of "sensible logging" - capturing as much meaningful information as possible while not overdoing it. Logs can be a powerful ally when hunting down an issue or trying to provide documentation of a security issue. Log wisely, log on purpose.

On his Medium.com blog Andreas Creten has written up a post that tries to answer the question "Does code need to be perfect?" As developers we have a drive to take pride in our work and want it to be the best code possible. However, that can lead to some bad practices...

In the past months I have asked myself a lot why we always strive to write perfect code. Picking up coding again for an internal project made me realise our team (and probably a large part of the rest of the software development world) spend a lot of time on writing perfectly formatted, ordered, patterned and tested code. But is this really necessary?

[...] The engineers want to write perfect code using the latest techniques, make sure that the code is well documented so they can fully understand how everything works and that it has tests so they can easily update things later. Product owners on the other hand just want things to be done, fast and cheap, so they can ship new features or convince new clients. How can you make these conflicting views work together?

He offers a few different suggestions for those developers wanting to craft the perfect codebase including coding for "now" not the future and the fact that "perfect code" just doesn't exist. He offers some suggestions for dealing with that "non-perfect code" you come across in your codebase, when starting from scratch makes sense and thinking about how "perfect" the code needs to be at the outset.

Peter Petermann has shared a few of his thoughts about right and wrong things to do when using Composer in your PHP-based applications. He offers suggestions based on some of the more wide-spread (but wrong, in his opinion) practices he's seen in several projects.

Last year I wrote a piece called “a few thoughts about composer and how people use it“. In that post I had a list of things which are problematic about how composer is used. That post got widely recognized, linked an visited, but in general those issues still exist.

However lately I’ve had even more people asking questions (either on related forums, irc or even irl) about problems that stem from issue number 2: people are using composer as an installer (and sometimes Number 3 because of Number 2). In that Post I already gave a quick opinion on how workflows with composer should look like, In this post I’ll try to give a few more pointers on how to use composer without creating a mess.

He then breaks up the remainder of the post into various practices he's seen and calling out developers for doing including:

• starting a project vs installing
• globally installed composer packages
• tagging and building

With each of his points he makes suggestions about what's wrong about the practice as well as some suggestions about how things could be done better.

In his post on his Medium.com site Ted Blackman looks at something he calls "Lug-nut driven development" (or, shortened LuDDite). He breaks it down into a few different suggestions including "build the whole thing badly" out to "automate stop and start".

These are practices that I’ve applauded myself for doing at the beginning of some projects, and kicked myself for not doing early enough in other projects.

The full list suggests things like:

• Building a system that goes through the whole flow first (not perfect) then come back and refine
• Testing as you go instead of coming back at the end and retrofitting them
• Log everything you can then cut back and refine
• Plan out the error handling before hand to help make it consistent
• Be able to "stop" and "start" the system easily

While not all of these are specific to web applications there's some definite helpful advice in here, especially to those starting out on new projects.

On Slashdot today Michael Ross as posted a book review of Josh Lockhart's recently released O'Reilly book "Modern PHP".

In recent years, JavaScript has enjoyed a dramatic renaissance as it has been transformed from a browser scripting tool primarily used for special effects and form validation on web pages, to a substantial client-side programming language. Similarly, on the server side, after years as the target of criticism, the PHP computer programming language is seeing a revival, partly due to the addition of new capabilities, such as namespaces, traits, generators, closures, and components, among other improvements. PHP enthusiasts and detractors alike can learn more about these changes from the book Modern PHP: New Features and Good Practices, authored by Josh Lockhart.

In the rest of the review Michael provides an overview of the topics covered in the book and how it's divided up. He then covers each of these three sections, commenting on the contents and making a few recommendations for those not immediately familiar with the topics. He does point out that he felt there was some critical information missing on some topics that "would allow one to begin immediately applying that technique or resource to one's own coding." Overall, though, he found the book a good resource and recommends it to those looking for a source to learn about new trends and tools in PHP.