After reading PSR-1, some thoughts came up that I would like to share with the programming community in order to get stories about your experience.
PSR-1: Basic Coding Standard — A standard that recommends rules for formatting and coding. Styling is how to write code, and writing is what to write.
The subtext PSR-1 says that you should not use mixing of code and logical conclusions of the code. I put it a little not clearly, but then you will understand that PSR-1 does not recommend writing a class, displaying it on the screen and initializing properties in one file.
All PHP files must use either <?php or <?=. Everything is obvious and understandable here, the first tag says about the declaration of a php code section, and the second is a short echo record, that is, output.
The files should also be in UTF-8 encoding without BOM, which makes sense. There was once a case in a project where there were several programmers. So, there one somehow managed to insert a BOM symbol and because of this, parsing files broke.
It also says that it is not recommended to use multiple side effects.
Well, here the moment is extremely controversial. Although the standard recommends using an autoloader according to its PSR-0 and PSR-4 standards. On the one hand, yes, but there may be application initialization at a single entry point. In short, the moment is doubtful. In the same Yii2 this approach is not followed … I would not pay attention to this very recommendation.
Let’s go to the section of class names and namespaces (namespace). Here I agree that the class file should contain only this class, that the class should be in the namespace. Class naming should be in StudlyCaps format. We will not consider options for writing code for PHP versions <7.0, as there are some nuances, and the demand for versions below is quite small.
We name constants in uppercase, separating words with underscores DATE_APPROVED. Everything is logical and understandable here, there is no point in naming them like properties or variables. It is necessary to clearly distinguish constants from properties.
But with the naming of properties, I do not agree with the recommendations. PSR-1 recommends using one of the following formats: $StudlyCaps, $camelCase, or $under_score. I don’t really like the messy code and rely on the opinion of each programmer. Personally, I, probably like many programmers, believe that there is only one style to use, and it should be $camelCase. Moreover, the standard is tricky, it says that these rules can come from code suppliers of different levels … Now, if the naming standard was adopted specifically, there would be no disagreements. Although I have not seen writing code in a different format from camelCase for a long time.
With camelCase() method naming, I completely agree and support. It is logical that we name classes with a capital letter, constants with a small letter, methods with a small letter. And, in principle, you can distinguish one from the other simply by writing.
Thank you for your attention, I hope that the material was useful, although it is a statement of thoughts on reading PSR-1.
Top comments (4)
The point is to use whatever you prefer, but use it consistently.
A standard helps you with consistency. And as you will discover, once you start working on a same code base with multiple users, it is good to have a single preference, be it forced or not.
At the end of the day, it does not matter what your code looks like, but how it performs. And code performance is not limited to computers only. I mean, you need to maintain, extend, read and sell the code. The PSR standards aim for these qualities too, not just the looks.
I cannot but agree with you. I know very well about PSR and use it actively. It's just that I personally chose the path of readability instead of performance. I argue that the code can be supported without problems by other developers. At the same time, performance-oriented code is harder to maintain. "Read like a book" is my rule to which I adhere.
I did mean it that way. A good quality code base performs well in the aspect of maintainability, is easy to extend etc. I believe the PSR standards try to aim fol legibility too, while keepimg the constraints low, where possible.
But at the same time PSR allows for ambiguity in naming, as I suggest a strict approach.