Nick makes a good argument for why go to should not be used. His closing argument is that zealous programmers will abuse go to. Pete makes a similar argument that go to has too much potential for abuse from programmers that we can’t be bothered to explain the use of to and you are better off banning them.

It is a similar argument people make when arguing for gun restrictions. As the politicians will tell you, “Sure we trust you with a gun, but do you trust your neighbor or the guys from across town with them?”

The difference though is that you have a lot of choice over who you work with. If you are limiting your choice of language or features based on the fact that you work with bad programmers I think you are trading off against the wrong factor. Do you want to work with bad programmers? Removing dangerous features from a language will certainly remove possibilities from bad programmers shooting themselves in the foot. They still won’t be good programmers though.

How many bad programmers will you even work with? Companies tend to have fairly regular hiring standards, at least at any departmental level and in my experience good programmers tend to work in the same place and bad programmers equally congregate. Indeed, in PeopleWare they demonstrated a strong correlation between programming ability and the layout of the office where they worked. If there is a strong correlation between office layout and ability then programmers in the same office will have a strong correlation in programming ability amongst themselves.

The boogeyman of bad programmers is a false threat to individual programmers. You are very likely only working with bad programmers if you are a bad programmer yourself. As a good programmer working with other good programmers, is go to still a bad idea?