**We can disagree and still be friends.**
I build bridges and tools for others to use.
I maintain and improve a lot of legacy code, monoliths, services.
I spend my free dev-time on FOSS packages.
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.
**We can disagree and still be friends.**
I build bridges and tools for others to use.
I maintain and improve a lot of legacy code, monoliths, services.
I spend my free dev-time on FOSS packages.
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.
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.