4 ms·

I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin defini

I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, you do need the latter a lot). Small functions can make code hard to understand because you need to jump to a lot of places and lose the thread on the sequential state (bonus points if the small functions are only ever used once by one other function). The more I work in code bases the more I find that overusing these "clean" ideas can obscure the code more than if it was just written plainly. I think a lot of times, if a technique confuses compiler optimization and static code analysis, it's probably going to confuse humans also.

wsc981 4y ago
There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it becomes kinda hard to maintain. And I tend to use an object oriented programming style (of course it also doesn't help that Lua is not typesafe). After I finish my current game, I want to try to make a game using a procedural approach. I wonder if this would solve some of the issues I see in my current code base. One of the core ideas of procedural programming is that data and functionality is not mixed in classes as we do in object oriented programming. Instead, you might have a module that contains some functions and some data objects the functions act upon. This approach would make some other aspects of game programming with Lua easier as well (e.g. serialisation), but perhaps it will make the code also easier maintainable as the size of the codebase grows. It's something I want to contemplate upon.
- NohatCoder 4y ago
  I think it is important to understand what makes a style actually different and what is just semantics. For instance, if you write a function to do some operation on an object, you could have written that as a method instead. But ultimately it is the same code, it is unlikely that the difference matters much for either performance or readability. However if you need to do some operation on a bunch of objects you could pack each operation on the individual objects in a method, and call those methods from a main function. Or you could just put it all in one function, with as many nested loops and if statements as there needs to be. Now the difference is real, you pay in performance for a lot of function calls, and following the control flow is different. Personally I tend to prefer the one function, but sometimes part of it makes sense as its own function, in particular when I can avoid duplication that way. There is no silver bullet, but best of luck, changing one's style can be hard.
- DeathArrow 4y ago
  When I am coding for myself I try to separate the data from the operations performed on it. I also think about how the data flows through the application. I use a mix of procedural and functional paradigms.
- overgard 4y ago
  Separating code from data definitely helps for serialization; while they aren't great for game development it's incredibly nice in typescript/javascript to do it that way. It can also help for things like network code or for cloning an object.
JustSomeNobody 4y ago
> a lot of "clean" code isn't really that much clearer and more maintainable at all Oh, it's not. Look at the crap the Java community used to produce. 37 levels of abstraction is not maintainable.

wsc981 4y ago

There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it becomes kinda hard to maintain. And I tend to use an object oriented programming style (of course it also doesn't help that Lua is not typesafe). After I finish my current game, I want to try to make a game using a procedural approach. I wonder if this would solve some of the issues I see in my current code base. One of the core ideas of procedural programming is that data and functionality is not mixed in classes as we do in object oriented programming. Instead, you might have a module that contains some functions and some data objects the functions act upon. This approach would make some other aspects of game programming with Lua easier as well (e.g. serialisation), but perhaps it will make the code also easier maintainable as the size of the codebase grows. It's something I want to contemplate upon.

NohatCoder 4y ago
I think it is important to understand what makes a style actually different and what is just semantics. For instance, if you write a function to do some operation on an object, you could have written that as a method instead. But ultimately it is the same code, it is unlikely that the difference matters much for either performance or readability. However if you need to do some operation on a bunch of objects you could pack each operation on the individual objects in a method, and call those methods from a main function. Or you could just put it all in one function, with as many nested loops and if statements as there needs to be. Now the difference is real, you pay in performance for a lot of function calls, and following the control flow is different. Personally I tend to prefer the one function, but sometimes part of it makes sense as its own function, in particular when I can avoid duplication that way. There is no silver bullet, but best of luck, changing one's style can be hard.
DeathArrow 4y ago
When I am coding for myself I try to separate the data from the operations performed on it. I also think about how the data flows through the application. I use a mix of procedural and functional paradigms.
overgard 4y ago
Separating code from data definitely helps for serialization; while they aren't great for game development it's incredibly nice in typescript/javascript to do it that way. It can also help for things like network code or for cloning an object.

JustSomeNobody 4y ago

> a lot of "clean" code isn't really that much clearer and more maintainable at all Oh, it's not. Look at the crap the Java community used to produce. 37 levels of abstraction is not maintainable.