Top stupidest programming polemics

1. Gotos considered evil
For too long, schools have been successfully spreading the fallacy that gotos should never be used. Whenever I write code for someone and I use a goto, someone always complain:
"Man, you used gotos to [Handle errors/Break out of multiple loops/we]"
So knowing usually the kind of people I'm dealing with I respond:
"Why?"
But people always fail to know the real reason gotos used to be bashed on:
"They're just evil..."

2. Tabs vs. Spaces for indentation
Everyone using a real text editor knows that tabs are by far superior to spaces. There are easily at least five times more reasons to use tabs than to use spaces. Even worse than that, the reason I hear the most often to use spaces is that "tabs don't have the same number of spaces in text editors" while IT IS THE WHOLE FUCKING IDEA OF USING TABS, ANYONE CAN SEE AS MANY SPACES AS THEY WANT.


3. Global variables are bad

No. Just like gotos, they are when idiots don't know when to use them.

>>14,15
That's a misuse of global variables.  What if library A has a function that looks like


void unexpert_programmer()
{
    while(1)
        ;
}

That's fucking stupid as well, but I don't see you cautioning that while loops should be avoided. It is the fault of the author of unexpert_programmer() that it does what it does, just as it is the fault of the authors of A and B that they attempt to set up a global state in a situation that should not use a global state*.

The issue is that most situations that use global variables can be rewritten to not use global variables, just as most situations that use goto can be rewritten to not use goto. So in order to cleanly eliminate classes of errors, those constructs are avoided entirely, even when they are actually perfectly logical. Hell, that's why languages have GC, to (attempt to) eliminate an entire class of memory leak errors.

And that's what OP's point was: that in the noble-hearted interest of reducing errors, we have been overzealous and removed useful constructions, with the slightly negative side effect that programmers demonize the constructs, not the errors they sometimes help create.

*No, not all code is library code, or should be written as if it is.