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.
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.