In a new post to his site Nikola Posa takes a look at naming conventions in code and makes some recommendations based on his own work.

In the last couple of months, I spent a lot of time studying Proophessor Do demo project that showcases features of Prooph components, all with the aim of mastering CQRS/Event Sourcing concepts. Along the way, something else turned my attention away from the main topic - unconventional, but clean and concise naming convention for class and method names.

This was a true eye-opener for me, I immediately liked the idea and after adapting it a bit I started practicing it at work. Excited and full of enthusiasm, I shared my findings and opinions with the rest of the world.

He tweeted about his excitement but found that there was more to say and a blog post was the place to put it. So in this post he covers several "anti-patterns" to avoid in code naming conventions:

• Anti-pattern 1: Prefixes/suffixes convention for Interfaces
• Anti-pattern 2: Archetype suffix convention for domain classes
• Anti-pattern 3: "get" prefix convention for property accessors

He finishes the post with some final thoughts and a "TL;DR" image showing a "right" and "wrong" way to structure your code.

The North Meets South podcast, hosted by Jacob Bennett and Michael Dyrynda, has posted their latest episode: Episode #32 - Conventions, configuration, and becoming a lead developer.

Topics mentioned in this show include:

• Laravel's Responsible Interface
• An article about the ex-Googler's manifesto
• Computed properties in Vue.js
• the osTicket ticketing system

You can listen to this latest episode either using the in-page audio player or by downloading the show for listening offline. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter to get the latest updates when new episodes are released.

In a new post to his site Nikola Poša has suggested some testing conventions he's worked up over his time in development across projects.

Testing is an essential aspect of development, and test code should be treated the same way with regard to defining and using coding conventions and standards.

This time I would like to share few conventions that I follow when writing unit tests in particular, some of which I adopted only recently.

He breaks it down into three main sections:

• Structure (file locations and namespacing)
• Naming (files and testing methods)
• Arrange-Act-Assert with exceptions and test doubles

Example code is included showing the concepts and implementation of the suggested convention, just to name a few.

While not specific to PHP (the examples are in Ruby, in fact) this new tutorial on the Toptal.com blog has some good information and suggestions around the use of exceptions in your applications.

Exceptions require special treatment, and an unhandled exception may cause unexpected behavior. The results are often spectacular.

Over time, these errors, and countless others [...] contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming; they exist to make our software better. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable.

They start by talking about why exception handling is a good thing and some common practices to help make them more manageable. They suggest that good exception handling can also help make your code more maintainable, extensible and readable in the long run. He suggests creating your own kind of exception hierarchy (more possible in PHP 7) and using them to get more specific on the type of exception that was thrown. He recommends not "rescuing" exceptions more than needed (in PHP this is try/catch) and that it's okay to defer the handling for the exception being thrown and not deal with it right away.

He also reminds you that not all exceptions need handling in your own code (sometimes it's up to the user) and that following conventions on naming can help end users better understand why there's an error. Finally, he recommends logging exceptions as they're major errors in your application, not just data problems or smaller bugs.

Paul Jones has a post to his site looking at SQL schema naming conventions and some of his own thoughts on the matter. There's a lot of different camps of thought around naming, much less database ones, and he makes a few suggestions learned from his experience over time.

Several weeks ago I asked on Twitter for SQL schema naming conventions from DBA professionals. (I’m always interested in the generally-accepted practices of related professions; when I can, I try to make my work as compatible with theirs as possible.)

I got back only a handful of responses, representing MySQL, PostgreSQL, and DB2 administrators, really not enough for a statistically useful sample. Even so, I’m going to present their anonymized responses here, because they led me to work I had not previously considered at length.

He asked about things like singular vs plural names, primary key choices and naming of association tables. The uses the rest of the post sharing the responses he got from his questions with a good range of responses representing both sides of each question. He wraps up the post looking at what these answers mean to the average developer and the answers that Joe Celko and Simon Holywell have to say on the matter.

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

• the overall style of the code
• the structure of the application (directories, libraries used, etc)
• naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

In this new post to Medium Frank de Jonge talks about one of the infamous "two things hard about programming", namely...well, naming things.

The other day I had a small discussion on one of my open-source projects, in this case Flysystem. It was about the smallest thing ever, the name of a method. A method name that was suggested to replace another method name just didn’t feel right to me. It made me wonder why. I came to the conclusion: Using lingo in code should be avoided.

He elaborates a bit on what he means by "coding lingo" and a few general things to think about when naming your methods, variables, etc. His reminders include:

• Going for clarity
• Remembering that not everyone is English
• That it can be excluding
• It can be limiting

He reminds us that naming doesn't have to be "cool", it just needs to be useful and a developer-focused kind of documentation. He recommends using common names/terms for things, being concrete and avoiding abbreviation. There's a few other recommendations in the post too, so check out the full article for more.

As is mentioned in this new post to PHPMaster.com, the PHP standards group is officially in the voting process on two new standards (PSR-0 being the first) setting up some standard development practices for PHP applications - PSR-1 and PSR-2.

They initially started out as one proposal but the initial round of voting didn’t yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals - one for mandatory interoperability and one for suggested style.

The PSR-1 standard proposes some basic coding standards (like namespacing structure and class/method naming definitions) and the PSR-2 standard covers similar things, but more in-depth with more recommendations.

If you want to find out how your application stacks up against this new standard, you can try out PHP-CS-Fixer (from Fabien Potencier) to see how many things need an update.

On the Web Scripting Blog today, Satya Prakash has a reminder for developers and those hiring them alike - PHP is not Java.

I went for Interview and there interviewer asked me few questions. I disagreed on two questions and their answers. [...] After I disagreed [about parentheses being required on class creation] they said it is essential in new PHP version 5.2.x. Still I disagreed then he said, no no after PHP 5.2.x, PHP is like Java. [...] I like PHP and I do not want it to become Java. If just by implementing Object Oriented Programming PHP can become Java then I will say Java is C++ or Java copied C++.

He proves his stance with a bit of sample code showing that the object creation doesn't require the parentheses to create.

On NETTUTS.com there's a new article that list nine different conventions that developers (PHP, Javascript, general web) could get confused about when they are just starting out.

Especially when first getting started with various web development languages, it can prove to be a difficult task to learn all of the various naming conventions from language to language. This can be even more confusing when developers disagree on what’s considered best practice. To help ease the transition for beginners, this list will describe some of the more common conventions.

Some of the conventions that they mention that are more specific to PHP developers are underscores before property names, uppercase constants, capitalized first letters in variables and alternative syntax (like ternary).