|
Authored by: Anonymous on Sunday, May 20 2012 @ 12:50 PM EDT |
That's what brainwashed structured programmers CLAIM, but they
produce as much,
if not more, spaghetti code as non-structured programmers.
Structured
programming is sometimes not capable of easily implementing a design,
then
structured programmers turn out the most bizarre spaghetti code ever seen
trying
to FORCE it into a structure. There's nothing inherently bad about using
GOTO -
it's bad programmers that turn out bad code, not GOTOs.
:P
I won't debate you on bad programmers, but I have NEVER run
into a situation where a structured languages like Pascal, Modula, C, C++, Java,
ML, or Ocaml has forced me into using spaghetti like coding methods. On the
contrary, I've often run across poorly designed algorithms that were implemented
in spaghetti code fashion. Often they were patched again and again when they
really should have be refactored. More often than not simple transformations
made them easily readable. To program well you really need to know your math so
you know you can transform one program structure into another and not introduce
errors. There needs to be a programming course on the programming equivalents
of the standard mathematical transformations. [ Reply to This | Parent | # ]
|
|
Authored by: jesse on Sunday, May 20 2012 @ 08:12 PM EDT |
Good programmers will produce bad code...
But frequently it is up to the protocol designer.
The only place I have seen a "go to" in C as absolutely necessary was
in a Kerberos packet decryption. The rather obtuse requirements made it a
necessity to use a state table which inherently has LOTS of go to structures to
implement.
Many TCP/IP protocols have this problem (one of the worst is telnet).
Much of the problem has to do with error handling and recovery.
C++ attempts to get around some of this by hiding things like garbage collection
by reclaiming structures when leaving a scope - but it is still implemented by
using tons of "go to" scattered all over the place.
So some of the blame has to go to communications people that don't really
understand coding practice and design protocols that cannot be properly
implemented.
Now that said, it also applies to compilers. Error reporting and recovery is one
of the hardest things to do. Even a simple grammar becomes a horrible looking
state table when all the error handling and recovery gets added.
For examples of that, just look at the output of Bison/Yacc when applied to even
a simple grammar.[ Reply to This | Parent | # ]
|
|
|
|
|