7 ms·

Many people fret about spaghetti code. Personally, I also fear lasagna code - too many layers, often with poor separation.

by rvense 5y ago

nine_zeros 5y ago
Describes my workplace. Too pedantic on layers and abstractions. Endless code reviews over nonsense. Before anyone says this - we have linters. The problem is nits about how the code reviewer would do things. The pedants also can't figure why nothing gets done.
- fridif 5y ago
  Code should be judged by inputs and outputs only! I hate code reviews. We end up rewriting well-structured code anyway simply because it is always easier to rewrite than to do surgery
  - villasv 5y ago
    That’s a bit too extreme to me (and already covered by unit tests). Code reviews are good mostly for asking questions, not dictating changes.
    - fridif 5y ago
      I do agree but too often they turn into "well I would do it this way". If it is some very big and very critical system then yes, code reviews can be beneficial compared to the alternative. But for systems that are innovative and rapidly going through iterations as it is, it's better to judge coverage of test cases (and adequate performance but not optimal)
  - sidpatil 5y ago
    What about performance? E.g. you don't want to implement an O(n) algorithm if an O(log(n)) equivalent exists, and merely testing inputs and outputs won't reveal that.
    - fridif 5y ago
      I do agree, but it depends on the criticality of performance and the level of change the system goes through by default. For us we are always implementing complex new logic for not very many users, so there's not much benefit to some clever data structure that we are all too dumb to understand. If I get a ticket that involves inserting something into the logic you wrote, and I can't understand how to operate your current solution, I will be hacking up an n logn solution as long as it is adequately performant
- 6nf 5y ago
  Company I worked for got some new management and they decided to add 3 more layers to our stack. THREE new layers. I talked them out of one of these but it wasn't enough. I'm no longer working there so I hope it works out for them.
- giovannibonetti 5y ago
  I blame object orientation. It is too easy to create useless classes. Funcional programming data types, on the other hand, are much more direct to the point, which makes it easier to spot useless layers.
  - YZF 5y ago
    It happens everywhere, not just OO. It's just human nature. I worked on C code where there were 8 layers of calls where each function was f() {return next_layer_f();} . The thing is sometimes layers serve a function and sometimes they don't. Then there's an always present pressure to look "professional" and so tons of layers and lots of details/checklists. The 4 lines of code that actually does everything you need doesn't cut it. And what will you do the rest of your day? The funny/sad thing is it doesn't matter how hard you try to fight human nature it doesn't seem to work. I love how the Go developers thought `go fmt` will end the formatting nitpicks. Guess what, it doesn't. We just found other things to nitpick. Or "Agile" or whatnot. Python says "A Foolish Consistency is the Hobgoblin of Little Minds" ... Well, try that on your co-worker in your next Python code review ;) Functional programming doesn't help either. In very small teams/companies sometimes the stars align and magic happens but it's really hard. EDIT: Also nothing to do with the article ;) though maybe we can dream up some connection to the human brain.
  - RedShift1 5y ago
    I used to be balls deep into OOP. I was in the rabbit hole. For me it was _the_ way programs had to be written. Whenever I started a new project, it would start out as a bunch of interfaces and abstract classes (with the god abstract class which everything extended from present and accounted for). At the time there was also the transition from PHP 4 to PHP 5 which unlocked a treasure trove of new OOP features and obviously every one of those features had to be used. However when things went wrong they would often turn into a nightmare, spending hours chasing down obscure bugs with endless print_r's to follow state changes. Over time I became better at managing this, keeping the amount of abstractions lower and just general better OOP design, but I was still afraid whenever things would go south, it meant hours of debugging, as was often the case. At one point or another I started asking questions about OOP design, the nature and origin of it and searched the internet for answers. Along the way I started realizing that many of the problems I was having are intrinsic to OOP. Whenever I would search for solutions to the complexity of OOP the answer would always be: you're doing it wrong. Along the way I transitioned to OOP-less programming (I'm calling it OOP-less because I don't want to start a fight over "functional" vs "procedural" vs "..." etc...), not with the intention to do away with OOP but just to play with it. I rewrote some earlier, simple programs and what became rapidly obvious was how easy the code was to debug. The datastructures I had written prior were way too complex with too many levels and useless wrappers to make everything fit into the OOP paradigm. I rapidly became annoyed with the complexity of OOP and realized, I was in a rabbit hole and I had dug in _deep_. Even now when I'm writing bigger programs OOP-less I still find them much easier to debug. I'm still afraid debugging sessions can get rough but as time passes by this seems like more of a PTSD effect from my 15 year long OOP stint. By now I've mostly done away with OOP programs but it's still annoying to have to interface with OOP designed libraries. I also changed my coding style camelCase to snake_case and the latter is much more legible to me but as a lot of libraries use camelCase or PascalCase it doesn't make the code look pretty. So yes long story short, I share your assignment of blame. Complexity just seems to be the nature of the beast.
- speed_spread 5y ago
  Code reviews are misunderstood. They're not about code quality, but about programmer quality. Yes, juniors get to learn tricks from the old monkeys (I'm one btw). But conversely, old monkeys should learn to accept variance in code where the implementation is not absolutely critical.
didibus 5y ago
You don't want pasta in your code, and there's more than spaghetti code, like lasagna code, ravioli code, etc. https://wiki.c2.com/?PastaCode https://wiki.c2.com/?PastaCode
deleted 5y ago
[deleted]

Many people fret about spaghetti code. Personally, I also fear lasagna code - too many layers, often with poor separation.

by rvense 5y ago

Many people fret about spaghetti code. Personally, I also fear lasagna code - too many layers, often with poor separation.

nine_zeros 5y ago

Describes my workplace. Too pedantic on layers and abstractions. Endless code reviews over nonsense. Before anyone says this - we have linters. The problem is nits about how the code reviewer would do things. The pedants also can't figure why nothing gets done.

fridif 5y ago
Code should be judged by inputs and outputs only! I hate code reviews. We end up rewriting well-structured code anyway simply because it is always easier to rewrite than to do surgery
- villasv 5y ago
  That’s a bit too extreme to me (and already covered by unit tests). Code reviews are good mostly for asking questions, not dictating changes.
  - fridif 5y ago
    I do agree but too often they turn into "well I would do it this way". If it is some very big and very critical system then yes, code reviews can be beneficial compared to the alternative. But for systems that are innovative and rapidly going through iterations as it is, it's better to judge coverage of test cases (and adequate performance but not optimal)
- sidpatil 5y ago
  What about performance? E.g. you don't want to implement an O(n) algorithm if an O(log(n)) equivalent exists, and merely testing inputs and outputs won't reveal that.
  - fridif 5y ago
    I do agree, but it depends on the criticality of performance and the level of change the system goes through by default. For us we are always implementing complex new logic for not very many users, so there's not much benefit to some clever data structure that we are all too dumb to understand. If I get a ticket that involves inserting something into the logic you wrote, and I can't understand how to operate your current solution, I will be hacking up an n logn solution as long as it is adequately performant
6nf 5y ago
Company I worked for got some new management and they decided to add 3 more layers to our stack. THREE new layers. I talked them out of one of these but it wasn't enough. I'm no longer working there so I hope it works out for them.
giovannibonetti 5y ago
I blame object orientation. It is too easy to create useless classes. Funcional programming data types, on the other hand, are much more direct to the point, which makes it easier to spot useless layers.
- YZF 5y ago
  It happens everywhere, not just OO. It's just human nature. I worked on C code where there were 8 layers of calls where each function was f() {return next_layer_f();} . The thing is sometimes layers serve a function and sometimes they don't. Then there's an always present pressure to look "professional" and so tons of layers and lots of details/checklists. The 4 lines of code that actually does everything you need doesn't cut it. And what will you do the rest of your day? The funny/sad thing is it doesn't matter how hard you try to fight human nature it doesn't seem to work. I love how the Go developers thought `go fmt` will end the formatting nitpicks. Guess what, it doesn't. We just found other things to nitpick. Or "Agile" or whatnot. Python says "A Foolish Consistency is the Hobgoblin of Little Minds" ... Well, try that on your co-worker in your next Python code review ;) Functional programming doesn't help either. In very small teams/companies sometimes the stars align and magic happens but it's really hard. EDIT: Also nothing to do with the article ;) though maybe we can dream up some connection to the human brain.
- RedShift1 5y ago
  I used to be balls deep into OOP. I was in the rabbit hole. For me it was _the_ way programs had to be written. Whenever I started a new project, it would start out as a bunch of interfaces and abstract classes (with the god abstract class which everything extended from present and accounted for). At the time there was also the transition from PHP 4 to PHP 5 which unlocked a treasure trove of new OOP features and obviously every one of those features had to be used. However when things went wrong they would often turn into a nightmare, spending hours chasing down obscure bugs with endless print_r's to follow state changes. Over time I became better at managing this, keeping the amount of abstractions lower and just general better OOP design, but I was still afraid whenever things would go south, it meant hours of debugging, as was often the case. At one point or another I started asking questions about OOP design, the nature and origin of it and searched the internet for answers. Along the way I started realizing that many of the problems I was having are intrinsic to OOP. Whenever I would search for solutions to the complexity of OOP the answer would always be: you're doing it wrong. Along the way I transitioned to OOP-less programming (I'm calling it OOP-less because I don't want to start a fight over "functional" vs "procedural" vs "..." etc...), not with the intention to do away with OOP but just to play with it. I rewrote some earlier, simple programs and what became rapidly obvious was how easy the code was to debug. The datastructures I had written prior were way too complex with too many levels and useless wrappers to make everything fit into the OOP paradigm. I rapidly became annoyed with the complexity of OOP and realized, I was in a rabbit hole and I had dug in _deep_. Even now when I'm writing bigger programs OOP-less I still find them much easier to debug. I'm still afraid debugging sessions can get rough but as time passes by this seems like more of a PTSD effect from my 15 year long OOP stint. By now I've mostly done away with OOP programs but it's still annoying to have to interface with OOP designed libraries. I also changed my coding style camelCase to snake_case and the latter is much more legible to me but as a lot of libraries use camelCase or PascalCase it doesn't make the code look pretty. So yes long story short, I share your assignment of blame. Complexity just seems to be the nature of the beast.
speed_spread 5y ago
Code reviews are misunderstood. They're not about code quality, but about programmer quality. Yes, juniors get to learn tricks from the old monkeys (I'm one btw). But conversely, old monkeys should learn to accept variance in code where the implementation is not absolutely critical.

didibus 5y ago

You don't want pasta in your code, and there's more than spaghetti code, like lasagna code, ravioli code, etc. https://wiki.c2.com/?PastaCode https://wiki.c2.com/?PastaCode

deleted 5y ago

[deleted]