I agree that writing a clean code is necessary. But I have something to add:
1) Decide whether you're using a camel case or not and stick to it, don't mix it up (I personally prefer using camel case in my projects).
2) Only one return statement per function - makes it much easier to read and debug, less likely to have hidden bugs.
3) I don't agree that naming a variable $bob or $whatever to rename it later is a good solution, you could easily forget to do this or be to "tired and lazy" after finishing with the feature. I always name variables clearly from the moment I create it, yes, it could be not easy at first, but you get used to it and it becomes automatic. And if later you decide that you don't like the name, you could always change it, but even if you don't - it still would be meaningful.
4) Also, it doesn't feel right when I see OOP mixed up with functional programming.
Here's my variation of this code:
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree that writing a clean code is necessary. But I have something to add:
1) Decide whether you're using a camel case or not and stick to it, don't mix it up (I personally prefer using camel case in my projects).
2) Only one return statement per function - makes it much easier to read and debug, less likely to have hidden bugs.
3) I don't agree that naming a variable $bob or $whatever to rename it later is a good solution, you could easily forget to do this or be to "tired and lazy" after finishing with the feature. I always name variables clearly from the moment I create it, yes, it could be not easy at first, but you get used to it and it becomes automatic. And if later you decide that you don't like the name, you could always change it, but even if you don't - it still would be meaningful.
4) Also, it doesn't feel right when I see OOP mixed up with functional programming.
Here's my variation of this code: