Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #144461

Re: Alternatives to spaghetti code

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: Alternatives to spaghetti code
Date 2019-06-05 09:03 +0200
Organization A noiseless patient Spider
Message-ID <qd7pf6$1e0$1@dont-email.me> (permalink)
References <75690eea-6786-40e5-8201-cbbf3133b26b@googlegroups.com> <lnv9xkvmds.fsf@kst-u.example.com>

Show all headers | View raw


On 05/06/2019 03:42, Keith Thompson wrote:
> luser droog <luser.droog@gmail.com> writes:
>> Spaghetti code is obviously bad news, but what about other
>> types of pasta-modeled code. Are there similar problems with
>> tortellini code or lasagna code?
> 
> Probably a joke, but there are other pasta-derived terms for bad code.
> 
> https://en.wikipedia.org/wiki/Spaghetti_code#Related_phrases
> 
>     Ravioli code is a term specific to object-oriented
>     programming. It describes code that comprises well-structured
>     classes that are easy to understand in isolation, but difficult
>     to understand as a whole.
> 
>     Lasagna code refers to code whose layers are so complicated and
>     intertwined that making a change in one layer would necessitate
>     changes in all other layers.
> 

When I talk about "lasagne code", I don't see the layers as being
intertwined - merely that there are lots and lots of layers.

I see this often in "software development kits" for microcontrollers.
Often in this sort of programming, you need efficient code - small, fast
code means smaller, cheaper devices, lower power, easier electronics,
etc.  And whereas modern x86 cpus excel at getting fast results from
inefficient code, with their superscaler execution, branch predictions,
register renaming, etc., on embedded microcontrollers inefficient
assembly means poor results.  Very often, actions on the microcontroller
actually only need simple code - driving a pin or sending a character on
a UART might not need anything more than writing a value to a specific
fixed address for a hardware register.  But SDK's with their layers of
drivers, abstractions, indirections, etc., can easily mean you have a
half-dozen nested function calls to get to that single write
instruction, and a half-dozen returns, with each function in the path
doing nothing useful except passing on responsibility to the next one.

So that is what /I/ mean by "lasagne code".  (It is quite different from
code where you /usefully/ have layers for abstractions and interfaces.)



You could have "tagliatelle code", which looks modular when viewed from
a distance, but on closer inspection each module is a tangled mess.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Alternatives to spaghetti code luser droog <luser.droog@gmail.com> - 2019-06-04 16:57 -0700
  Re: Alternatives to spaghetti code Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2019-06-05 01:59 +0200
  Re: Alternatives to spaghetti code nobody@example.org (Scott) - 2019-06-05 01:09 +0000
    Re: Alternatives to spaghetti code fir <profesor.fir@gmail.com> - 2019-06-05 06:19 -0700
      Re: Alternatives to spaghetti code fir <profesor.fir@gmail.com> - 2019-06-05 06:49 -0700
        Re: Alternatives to spaghetti code fir <profesor.fir@gmail.com> - 2019-06-05 07:05 -0700
      Re: Alternatives to spaghetti code fir <profesor.fir@gmail.com> - 2019-06-05 07:19 -0700
  Re: Alternatives to spaghetti code Keith Thompson <kst-u@mib.org> - 2019-06-04 18:42 -0700
    Re: Alternatives to spaghetti code David Brown <david.brown@hesbynett.no> - 2019-06-05 09:03 +0200
      Re: Alternatives to spaghetti code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-06-06 18:34 +0000
    Re: Alternatives to spaghetti code mark.bluemel@gmail.com - 2019-06-05 02:46 -0700
  Re: Alternatives to spaghetti code Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-05 06:45 -0700
    Re: Alternatives to spaghetti code fir <profesor.fir@gmail.com> - 2019-06-05 06:54 -0700

csiph-web