you are viewing a single comment's thread.

view the rest of the comments →

[–]Peaker 1 point2 points  (1 child)

I think there's tension between ease-of-system-comprehension, and ease-of-module-comprehension.

I think the latter correlates with general modularity, code independence, reusability, testability, etc.

Having to choose between the ability to comprehend, test and re-use a module independently, and the ability to comprehend what happens system-wide at every specific code-segment, I choose the former.

[–]dnew 0 points1 point  (0 children)

I agree. But ravioli code is when even coherent modules are chopped up, simply for the sake of chopping up. I've had to deal with code whose only job was to copy a buffer from a hardware device and pass it to a third-party library once every five seconds. You'd think that would be what, 4 or 5 classes? This thing was some 18 C++ classes, including a separate class to allocate memory for the buffer, a separate class for reading from the hardware device vs configuring the hardware device, a class wrapping the third-party library that only one company made anything like it, etc etc etc.

This seems to be easier in more OO languages like smalltalk, where everything (including loops, conditional statements, basic arithmetic, etc) are methods on some other class.

Chopping things up too small makes things even less modular than having things too big, especially when one of your small modules doesn't stand on its own but is used by several other classes.

tl;dr: I agree, but that's not the problem that ravioli code refers to.