Most of us are probably familiar enough with spaghetti code, where the logic jumps around a lot. It was a much bigger problem in assembly language and earlier compiler languages which lacked so-called "structured" statements and basically had to do a lot of GoTo-ing.
Then more and more languages adopted "bracketing" (Begin/End, {}, etc.) and case statements and such. This led to another term lasagne code which was usually reserved for code that was written to nest bracketed code deeply. When indented you might find yourself with a vast amount of ragged whitespace at the left and a lot of code shoved far to the right.
While lasgne was a cure for most spaghetti, the usual attempt to prevent or correct it in turn was ravioli code. Here you more or less grab hunks out of the lasagne layers and make them separate procedures called from the original spot.
The downsides of ravioli include:
Now, efficiency isn't everything. We know this. However there are times when it can be important.
As a concrete example I had a case where it was necessary to process XML documents of around 1KB to 100KB. Most would be on the smaller side, so I figured the cost of using a DOM shouldn't be too punishing. Of course that decision means accepting a certain level of overhead already, a DOM is hardly free compared to something like SAX parsing.
Due to the nature of this XML it was necessary to traverse node by node and deal with whatever namespace prefixes came, so it as necessary to check both namespaceURI and baseName to verify I had a "node of interest" and which one. Those of interest were nested five levels deep.
It was also possible for the XML to contain varying numbers of elements in varying namespaces to be ignored.
So the data extraction logic was five levels of traversing a childNodes collection for namespaces of interest and then based on the baseName take any of several possible actions (Select/Case).
Then at the bottom (innermost) layer different sorts of data needed to be extracted and converted to strong types. The DOM couldn't do the typing since these XML documents contain unsupported types such as "dateTime.rfc1123" and in many cases the XML documents might not even contain any data type attributes at all.
So basically, a big steaming pan of tall lasagne code.
![Name: TallLas.png
Views: 26
Size: 40.7 KB]()
Now, the common wisdom says to find appropriate layers to slice out and roll up into ravioli (additional procedures) - just on general principles.
When I tried this by cutting things out just at level 3 (the middle) and creating one additional procedure... benchmarks showed that execution costs nearly doubled. Twice nothing is nothing, but sadly this isn't the case here. The cost really mounted on the rarer large documents though.
I still haven't given up and may look harder for another place to slice and roll that won't require copying as much "state" data, perhaps getting cleverer about using globals and avoid passing anything "heavy" as parameters.
But my question is:
"When does maintainability trump performance" in this kind of case where it isn't just a question of using "tricky" techniques?
Then more and more languages adopted "bracketing" (Begin/End, {}, etc.) and case statements and such. This led to another term lasagne code which was usually reserved for code that was written to nest bracketed code deeply. When indented you might find yourself with a vast amount of ragged whitespace at the left and a lot of code shoved far to the right.
While lasgne was a cure for most spaghetti, the usual attempt to prevent or correct it in turn was ravioli code. Here you more or less grab hunks out of the lasagne layers and make them separate procedures called from the original spot.
The downsides of ravioli include:
- If the code is very stateful you may have to create globals you otherwise wouldn't need, and or pass long lists of parameters.
- If these lovely little dumplings of logic occur within loops changing them to procedure calls can add a lot of runtime overhead.
Now, efficiency isn't everything. We know this. However there are times when it can be important.
As a concrete example I had a case where it was necessary to process XML documents of around 1KB to 100KB. Most would be on the smaller side, so I figured the cost of using a DOM shouldn't be too punishing. Of course that decision means accepting a certain level of overhead already, a DOM is hardly free compared to something like SAX parsing.
Due to the nature of this XML it was necessary to traverse node by node and deal with whatever namespace prefixes came, so it as necessary to check both namespaceURI and baseName to verify I had a "node of interest" and which one. Those of interest were nested five levels deep.
It was also possible for the XML to contain varying numbers of elements in varying namespaces to be ignored.
So the data extraction logic was five levels of traversing a childNodes collection for namespaces of interest and then based on the baseName take any of several possible actions (Select/Case).
Then at the bottom (innermost) layer different sorts of data needed to be extracted and converted to strong types. The DOM couldn't do the typing since these XML documents contain unsupported types such as "dateTime.rfc1123" and in many cases the XML documents might not even contain any data type attributes at all.
So basically, a big steaming pan of tall lasagne code.
Now, the common wisdom says to find appropriate layers to slice out and roll up into ravioli (additional procedures) - just on general principles.
When I tried this by cutting things out just at level 3 (the middle) and creating one additional procedure... benchmarks showed that execution costs nearly doubled. Twice nothing is nothing, but sadly this isn't the case here. The cost really mounted on the rarer large documents though.
I still haven't given up and may look harder for another place to slice and roll that won't require copying as much "state" data, perhaps getting cleverer about using globals and avoid passing anything "heavy" as parameters.
But my question is:
"When does maintainability trump performance" in this kind of case where it isn't just a question of using "tricky" techniques?