They might not realise they're breaking the code when they write something. In the example I gave earlier, where $player->points should always be positive, it's not necessarily obvious that it should be. There's nothing in the variable name to say so. It might only be a very unusual set of circumstances where a negative score breaks the game.Jenk wrote:You mean wasting time by mis-using a library. The variable will be clear as to what it's purpose is, so why would they assign something to it that will break it?!onion2k wrote:Communicating is ace if it's worthwhile and constructive, but if you're talking about a code failure that could have been avoided by using private variables rather than public you're wasting everyone's time. Why would you want to do that?Jenk wrote:Heaven forbid colleagues would actually need to talk to each other.
If you've made a variable public a developer might accidentally typo a + as a - instead.. "$player->points -= 5;" for example.. it's easily done. That might be fine 999 times in 1000 when the players score is more than 5, but as soon as the code is called when the player has less than 5 points the game breaks.
If I'd written the code, and the developer had to use the setPoints method, because $player->points is private, there's no way their typo could break the game because the method uses abs() to correct the value.
What I'm failing to understand is why, if as you say yourself you never use public class variables, and you use a naming scheme to make this stuff obvious, you wouldn't enforce it in the code just to make sure. There's no difference really between using a naming scheme and using directives, apart from the directives actually make sure people don't ignore it. Which is good.