Programming in terms of how you think code should be written rather than programming the way you think the program should be written.  Your programming is limited to the 'ideal programming style', rather than other limitations like readability, the language, specifications, etc.

This is very much an issue of dogma, where there are certain techniques one never considers using for fear of making "unpure" code; these things are very often called 'evil' and are BadThing''''''s

Naturally, this a bad way to style, as the 'ideal programming style' rules are rules of thumb, such as GotoConsideredHarmful and SingleFunctionExitPoint, and breaking them will not be terribly bad, though harmful if done badly (as with all things in code).

In the 70's-ish people wrote lots of what's called SpaghettiCode, and came up with a general frame called StructuredProgramming to avoid it. 

''People shifted to StructuredProgramming because they eventually agreed it was more practical than Goto-centric code. It had little to do with "should-ness"; it was informal road-testing of an idea. Some newfangled ideas stick and some are dumped after tried for a while. This is not saying that everything that "sticks" or is long-lasting is the ideal. Sometimes sub-optimum "cultural habit" also sinks in. A lot of it is organic and thus somewhat messy and arbitrary. In my opinion, it's best to let somebody ''else'' try new ideas for 5 years or so if possible. Let them volunteer to be the Guinea Pig. -t''