[QUOTE]\nOn Sat, 2013-09-28, Rui Maciel wrote:\n\n\nOdd. I think I'm seeing the opposite in recent years: "Wow, I can\nfit in *and* break taboos at the same time, by using goto for error\nhandling! The Linux kernel does it so I can claim superiority by\nassociation!"\n[/QUOTE]\nThinking moves on. When I learnt to program, I was told that you had\nto flowchart before actually writing code. I even had a little stencil\nwith the flowchart symbols cut into it. But people weren't actually\nusing them for real development. Eventually it was admitted that they don't\nmake much sense when you can edit and run code interactively.Similarly, I went through a phase of never using gotos. But with increasing\nexperience and increasing confidence, you make your own judgments. Gradually\nthinking catches up, and now it's quite normal to see gotos used in error\nhandling.[QUOTE]\nI don't mind this when goto /is/ clearly the best approach. Or when\nthere wasn't time to do it better. I /do/ mind when the author didn't\nfind the better design (probably breaking the function down) simply\nbecause he wasn't looking.\n[/QUOTE]\nThe problem with "breaking the function down" is that it's no longer a leaf\nfunction. So it can't be cut and pasted, someone can't look at it and\ntell you exactly what it does, if it is changed, say to operate on reals\nrather than integers, the whole file rather than just a portion of it\nneeds to be checked, because there might be calls to the broken out\nsubroutines elsewhere. Then the subroutines themselves often aren't good\nfunctions, they might not make any sense except in the context of caller,\nwhich isn't what procedural decomposition should be about.\n\nThat's not to say that there should be a blanket no. Obviously you wouldn't\nwant the logical corollary, where the entire program is a single function.\nBut I'd be very reluctant to create a subroutine for the primary purpose of\navoiding a goto.