Blog

PSR-2 or how to be a better developer

15-04-2021 · in development

PSR-2 or how to be a better developer

In the PHP world the entire community was not so compact in the early days when it comes to the coding standards. The idea of having a coding standard is so hard to adopt to some of us and it is causing more trouble in the thinking process.
This is so evident when doing code reviews for example and can cause different useless talks inside the development team.

Advantages

PHP Standard Requirements (PSR) is the the go to point for any kind of PHP developer. From my experience I can say that adopting a code standard like PSR-2 comes with multiple benefits. I will try to list them here:

- software maintenance; this is the main point and the most important one. If you do a search you can find that from the cost perspective between 40 and 80 percent of the lifetime cost of a software goes into maintenance and also the fact the hardly any software is maintained its whole life by the author.

- code quality; software development work involves reading a lot of code. Either writing code or code review involves reading the code and this should not be perceived as something difficult to do or more beautifully said, as something annoying.

- keep it simple; the complexity of a code structure is fighting against security in most cases. If you try to minimize the amount of code written during the project development you will also write less (hidden) bugs

- refactoring; when renaming a variable, renaming a method or breaking code in smaller parts it is called refactoring. When the code looks clean and ordered then the refactoring process goes easy and well.

- code language; every developer should know English. All the documentations regarding parts of some software are in English. The guy coding after you knows also English so for all of the reasons above the code language is connected with the software maintenance process and is bringing a plus to the readability of the code.

PSR-2 conventions

The PSR-2 conventions make a lot of sense for me at least in overall code improvement.

Indenting

I read a lot of articles with talks about what is better, tab or spaces. For PSR-2 things are simple in my perspective: “Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.”.

Properties

Developers know that naming variables is the hardest thing to do so thinks like “Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.” or like “Visibility MUST be declared on all properties.” are here to help.

Closures

“Closures MUST be declared with a space after the function keyword, and a space before and after the use keyword.” To check out all the conventions for the PSR-2 standard please visit this link

Tools

A great tool to have some automation in checking the code standards is PHP CodeSniffer. To install it you can do something like

	apt install php-codesniffer

or if you have PEAR installed

	pear install PHP_CodeSniffer

After installation you can use it from the console for example like this

	phpcs --standard=PSR2 src/

Or you can set up your IDE to automatically check the coding standard using the phpcs.

Go ahead and be a better PHP developer

A good developer should follow a code standard. I am standing up for PSR-2 here but what code standard you should use it is up to you. The important thing is to have one and follow it strictly.

If you are a business owner or project owner talk with your developers about coding standards.
If you are a developer adopt a coding standard.

source1 source2 source3

Tests, tests … PHPUnit tests!

25-03-2021 · in freelancer

As a developer you encounter many ways of doing code, many ideas, some of them are nice and you are amazed on how nice and optimal is the implemented solution but some of them are really something that makes you wander about code and how a developer can write such a bad code.

Many times, this is covered in expressions like “ hey, it works” or “hey, we get the clients/money in, so all is ok”. Yes, this is 100% true but you need to understand, as a product owner or a business owner that this is what you call a medium product or even worse then this.

Recently, a customer provided his code to implement new features to me and I discovered a Laravel application with a SQL file :). Probably you have guessed … the migrations where not up to date with the database and the SQL file was the source of the “truth”.

freelancer laravel migration issues

If you wonder why or how can this be, it is very simple: life as a developer is like this; full of challenges. I remember when I was a junior developer I was scared of this situation and probably left the customer like this. With the time I learned to “own the mess”. This process is best described on the book “Clean Code” by Robert C. Martin (Uncle Bob).

Getting back to the customer, I was in the faze to tell him “hey this is crap, you need to pay more” or “hey, I am not doing this” because you can imagine that also in the rest of the code you can’t even think of something like PSR2. This is in my perspective the basic decent stuff a developer can at least do. Anyway, I “owned the mess” and carried on with my task. I looked on the SQL file, upgraded the hole migrations to a normal flow and moved on.

freelancer laravel migration fixing

You may wonder why I did this? My answer is the I am not afraid of the “legacy code” or of the “spaghetti code”, I usually find real gems in this kind of code and as a result of my effort I implemented PHPUnit tests.

This is another topic on why you should at least try to get tests implemented in your project and if you have a new project just use TDD. I know it is super time consuming and very stressful, but the benefits on the long run are huge. The stability and the reliability of your software will be always there! If the tests are written is a good way and you test the code right, you are close to become a better developer then the majority.

Laravel folder permissions

24-03-2021 · in snippets

Laravel requires some folders to be writable for the web server user. Using ACL
	// nginx = web server user
	// systemuser = your local/ssh user
	sudo setfacl -Rdm u:nginx:rwx,u:systemuser:rwx storage
	sudo setfacl -Rm u:nginx:rwx,u:systemuser:rwx storage
If you don't have ACL, you can use these but they're not so great;
	sudo chgrp -R www-data storage bootstrap/cache
	sudo chmod -R ug+rwx storage bootstrap/cache
source