Again this is flow insanity. Exceptions can break out of smooth flow threw program. Threads also can break out of smooth flow control. Speghetti is mostly a result of poor code quality management and coders taking short cuts here and there and they stacking up.

Like I will create a universal catch all exception handler and forget to include the useful information like where in by code base something went wrong. This can be a very small but highly inconvenient section of Spaghetti code. Rest might be sane design but if you exception handling is spaghetti you are fairly much up the creek.

The goto and label construct exist in C and many other languages. Still used in fact in the Linux kernel are part of error handling. But correctly. Correctly is beneficial to performance.

The link you have referred to has Spaghetti with meatballs code and traditional spaghetti code in the same define.

This is why I type traditional spaghetti code and Speghetti with meatballs code.

–In later languages, especially scripting languages, the use of include files or statements could often result in Spaghetti Code.–
This Speghetti with meatballs code in most cases. OOP control structures used poorly.

Yes there is a generic spaghetti code term that does not really mean much.

Most of the Spaghetti code issues when you look closely is poor code usage and poor quality code options selected.

Business layers mixed with each other does not have to happen for the code to be Speghetti. Speghetti style makes the code harder to read simpler to cause a memory leak or object leak or other nasty memory leak.

TM Repository there is a subset of Speghetti called rat’s nest this is the one with out layers with the spaghetti going in all directions bar lose with no sanity control.

–business layers with data layers and presentation layers.– This is rat’s nest code. Code that is rat’s nest is o my god this might be simpler to start over.

You can have Speghetti code with clean separation between layers. It is still Spaghetti code. Just Spaghetti breaking control struts of the language all over the place so is liking playing with a live hand bomb. Make one alteration and all hell can break lose.

Rat’s nest is the worst end of the Spaghetti scale. My examples are at the shallow end of the spaghetti scale.

Spaghetti code integrated into Lasagna code does exist. Its not in the class of rats nest spaghetti code but is pretty down right bad.

Just because you have a Lasagna looking code base does not mean layers in it are not full blown Spaghetti code. This is why the idea of mixing of layers is wrong. Key trait of Speghetti is breaking the control structs and the lack of smooth flow of the code.

Execution should smoothly flow down the program. Spaghetti does not show this trait as it gets worse. My simple examples only slightly break the flow I don’t have many gotos coming in from all over the place to the same label from above and bellow as you find in bad Spaghetti.

Really you can have a program that is really lost.

Yes a program Lasagna, Ravioli, traditional spaghetti, Spaghetti with meat balls and rats nest code. None of these types is 100 percent prevent being mixed up.

So one layer of the Lasagna might be traditional spaghetti mess. Another layer might be a Stack of Ravioli with instead good code inside Spaghetti code. Another layer might be a pure rats nest with no clear logic at all. Then you can find that the a rats nest has created links between the Laguna layers. Yes the rats nest code is called that because just like rats infesting houses that look find you can find rats nests infesting code bases that from a quick look seam to be sane Lasagna or Ravioli.

A program like this is result of code quality standards not being enforced.

TM Repository you are thinking mutually exclusive between the types. As programs we with that was the case. The problem is without checking the complete code base a section of spaghetti or over done Ravioli or over done Lasagne could go in the code base for a long time. This is why automated tools throw up errors about coder style.

TM Repository really you don’t understand the terms here.

Once again, spaghetti code is when you mix business layers with data layers and presentation layers. Each “noodle” is a different layer that’s interwoven. Get it?

The opposite of spaghetti code is “lasagna code” where data, logic and presentation layers are all separated. That’s what Model, View, Controller (MVC) is. Get it yet?

–Don’t worry – all I want is a sippet of C/C++ code. Nothing more.–
You asked for C and C++. Asm my example is not spaghetti there are not hidden control structures being broken.

C is a structured programming language. Its designed for structured style code. Using goto on C can turn into speghetti insanely quickly. Most cases insanity. The question is if the spaghetti is harmful or beneficial.

My example was 1 step away from harmful same with the wikipedia goto example. Only thing saving it is no memory declares in the if. Because both are breaking control structures. Close to disaster not disaster yet.

This is why speghetti code such a maintenance nightmare. Code that looks close to the same one can be a memory leak and one can be perfectly safe. Worse only a memory leak when built with particular complier options.

So to make it look 100 you could do like my if (c<10) goto start; twice.

The if is truely a break.

if (c<10) {
goto start;
}
Comes clear when you do the C code old school long hand. The {} are control structure broken in the first example. Modern day compliers you don't have to type the brackets because the compiler basically inserts them for you.

if (c<10) {
int x=10;
printf("%i\n",x);
goto start;
}
This brings a interesting question what happens now.

Depending on the complier you could have a memory leak. Why int x never made it to the free point at } this is because the control structures are broken by the goto.

This is why the goto can become a source of a disaster. I will just add some code to the if statement with a goto and the broken control structure.
if (c<10) {
int x=10;
printf("%i\n",x);
}
if (c<10) goto start;
This here is what you have todo to be sure not to leak memory. You must not break brackets(invisible or not) with goto that you declare memory that you cannot directly free before the goto in due to the broken control structure possibly causing the free not to happen.

for (int c = 1; c 10) {
goto end:
}
goto start;
end:

This is heading to messy spaghetti and is dirty.

The reality is without the if a never end goto loop done a particular way.

start:
goto start:

With no escape option speghetti since it does not break brackets that are control control structures. Not a good thing todo to end up in a never ending loop. Its the if statement where you break the control structures for the first time when you use goto. Its only going down hill from there if you are not careful.

That Exploit Guy you have forgotten these {} are control structures written or not.

The start of speghetti looks harmless. As the code expands the evil can appear.

There are times when using goto to break the control structs is valid. There are reasons why the goto has to be going forwards in the code. Even doing that you can cause memory leaks if you are not careful.

The fact that every if () goto breaks control structures a warning. Wikipedia example is a pure break. My example sorts the men out from the boys on exam. Does this program contain any broken control structures you would have answers no when the answer is yes 1 the if () goto combination.

spaghetti code starts with the possible valid uses and you add a few invalid like mine where a do while, for,while should have been used . The progressively the code base becomes a disaster zone as more and more control structures are broken without valid reason.

Traditional speghetti code comes from the over use of speghetti code and people like That Exploit Guy that does not have a clue what the control structures in C are and when they are breaking them.

‘Like instead of a for loop…’

I don’t see any “structs” there. Perhaps you mean “structures”?

Also, I don’t see any “spaghetti code” there since the goto statement is not breaking any control structures in the code (e.g. loops, if…else). Sure, one could have used “do…while” instead of “start… goto start” or even replaced the entire piece of code with “for (int c = 1; c <= 10; c++) printf("hi\n");", but that's besides the characteristics of “spaghetti code”.

Also, Edsger Dijkstra’s letter to ACM (“A Case against the GOTO Statement“) even explicitly states that his argument was against “the unbridled use of the go to statement” (bolded mine) rather than the mere usage of goto.

Also, try not to rely on Wikipedia too often. It is, after all, a quite unreliable source of information.

Like instead of a for loop
c=0;
start:
c++;
printf(“hi\n”);
if (c<10) goto start;

This is the start of traditional spaghetti code. Worse case in tradition spaghetti code done in c or c++ only main() {
} exists as a function. No OOP of any form. Just if goto and labels used to get around. No for, while, switch. Yes all the stuff of structured programming not used.

Good quality code checkers today will reject what I just did. They allow you goto to a point latter in the program you cannot goto to a point before the goto jump. This is a rule any good quality static checkers will enforces. Gotos most productive usage is error handling to go forwards in code to free memory struts safely.

This prevents goto triggered never ending loops.

To code tradition spaghetti code you don't have loop functions.

Good write up on the different names. http://en.wikipedia.org/wiki/Spaghetti_code

What a lot of people call speghetti code today is what is really called Spaghetti with meatballs code since OOP features are mixed up like functions.

Traditional spaghetti code is simple to find due to over use of goto.

Spaghetti with meatballs can be horrible. Coverity also has a habit of calling out spaghetti with meatballs code as well.

Each of these titles has a particular feature usage style to them. This is why its possible to design automated software to find coders not doing good style for lots of them.

The spaghetti and spaghetti with meatballs problems is the simplest to design checkers to find.

dirty code finding is harder.

Ravioli code and Lasagna code are down right hard to create detection for since at times the code that looks like that can be valid.

Basically dirty is always wrong. The speghetti code is almost always wrong. speghetti where the gotos only go to future points in the execution is the only form of speghetti that is valid. This is why both are simple to detect.

The example on the wikipedia a checker should throw an error for unrequired else and goto. Checking flow logic detects lots of human errors.

‘Flow control structs’? I, for one, would like to see an example of that.

Don’t worry – all I want is a sippet of C/C++ code. Nothing more.

traditional spaghetti code gotos and if as you only flow control structs. Also reusing buffers over and over again in different sections of code coverity does not particularly like either. So global buffers coverity will hate you.

Coverity I know supports windows. For Microsoft to use it they would have to pay and use it. The current IE bug would have been dug out by it. Its the kind of problem Coverity is designed to find.

Converity was because of spell checker.

–A Lint tool isn’t going to fix logical errors that the programmer has introduced!–

Particular programmer logic errors are detectable. Like using a variable after its freed or should have been freed.

Depends how advanced the Lint tool is basically. Advanced tools do checking of variable usage.

TM Repository
–Programmers aren’t psychic, though, and can only base their unit tests on past experience.–

This is why you use klee.llvm.org or coverity or others tools for automated test suite generation. These are software they build there own program unit tests based on the flow of the program. To make sure every code path gets executed.

Humans are fairly useless at making unit tests that properly test a program. Humans are good at making unit tests to make sure features users want is there.

TM Repository basically you are out of date. You are talking about using humans to make test suites that is old obsolete talking.

Automated test-suite generation with human tweaking is current day. The current fault in IE should have been dug out with Automated test-suite generated test-suite as well. Since that makes sure the error paths are checked.

We know programmers are not psychic this is why automated tools make large section of test suites and you also run fuzz testing. In the case you missed something.