6 ms·

I've noticed what I'd term a "post-modern" sensibility towards code quality, where some of the often cited tenets of good code are being critiqued or questioned

I've noticed what I'd term a "post-modern" sensibility towards code quality, where some of the often cited tenets of good code are being critiqued or questioned. Stuff like yes, you can have super large functions or super large files. Or yes, you can have repetitive code. Turns out a lot of this stuff doesn't impact readability or in fact is more readable than the alternative. I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. And I certainly don't need the levels of abstraction that design patterns or Haskell typeclasses demand. There's a real danger in a well-intentioned clean code advocate. First, because there are no universal code principles. Maybe "have it work", but even then, a lot of value has been gotten out of code that doesn't work. And second, because it's very easy to go from a good guideline to a dogma. All you need is a few people to misinterpret your guidelines. Heck, a lot of people haven't even read the guidelines. They just parrot what someone else paraphrased on Twitter.

agentultra 4y ago
> I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. And I certainly don't need the levels of abstraction that design patterns or Haskell typeclasses demand. I’d say it’s pretty subjective. I’m the opposite. I can’t read functions that are a hundred lines long with a dozen bound variables and half a dozen branches and early exits. That’s not easy to read and it requires keeping a notepad with you to figure out the control flow. I much prefer short definitions with clear logic. Leave the semantics to the edges of the program where it matters. It’s easier to reason about using substitution and algebraic manipulation. Don’t get me wrong though, I write my fair share of C code and low level drivers. For that though I tend to use a higher level language to work out the logic. My business isn’t writing code. That’s the boring part. It’s solving the problems that is interesting. But that’s the funny thing. Regardless we could both solve the same problems in our own ways and more often than not it will be good enough. After twenty years and hoping for another twenty… I guess I’ve learned that what matters is that you can get along with your team and read each other’s code. Styles come and go and don’t matter that much.
- 000ooo000 4y ago
  I'm with you re. short functions. Setting boundaries around code, i.e. scope, and giving that behaviour a well-defined signature (i.e. a descriptive name, what it needs, and what it gives back) makes it easier to reason about the overall functionality. Giant functions reduce my confidence that any given change isn't going to introduce a problem. I like to imagine each execution path through a function as a piece of string. The fewer strings, the fewer kinks, and the less string overall, the easier it is for my monkey brain to handle most of the time. Yes this is 'cyclomatic complexity', but strings are nicer visually :)
- wruza 4y ago
  That’s not easy to read and it requires keeping a notepad with you to figure out the control flow. It does require a notepad as well when a five-page long function gets smeared across three “services”, five files and tens of functions, each doing a couple lines of code. Leave the semantics to the edges of the program where it matters Agreed. But when I meet this highly-structured code (and get confused), it’s usually split not across semantics, but across some random undocumented ideas about reuse, undeclared abstractions, highly indirect flow control, etc. And all of that named as if it was a most bizarre naming contest. So that instead of a little hairy idea you get a convoluted irrational multi-plane horror to deal with.
  - agentultra 4y ago
    Yes, I understand. In highly procedural code the unprincipled combination of functions results in layers of indirection which do not make the code any easier to understand. It requires discipline to achieve what I call here, principled combination: that the combination of functions follow certain laws like they do in mathematics. In many programming languages it requires discipline because the type systems and the programming languages are not constructed in such a way as to uphold these laws for you. You, the programmer, have to enforce these laws on your code. That is why, when I'm writing something in C, I will some times prototype my design in a higher-level language first and translate that into C code. The higher level language is more principled and helps me catch errors in the design and development stage before I've made a mess of things. I don't always do it that way but it tends to work the best when I can get it to.
tombert 4y ago
One opinion that seems to have completely changed since I first learned is about having a single `return` in my function. It was hammered into my when I first learned that you should only ever have one exit in your code, anything else is bad practice. Fast forward about 11 years, and people realize that having a million nested if statements and matching else blocks is actually absurdly unreadable; much better to just return early, avoid nesting, and break the "only one exit" pattern.
- p1necone 4y ago
  I'm big fan of separating functions into validation and logic using early returns: function doSomeStuff(input) { if(someInvariantIsUnsatisfied(input)) { return Error; } if(someOtherInvariantIsUnsatisfied(input)) { return Error; } //do stuff return result; }
  - Jtsummers 4y ago
    The term for that is a "guard". Swift took it literally and introduced guard statements which force you to terminate the containing scope (return, throw, continue, break) or call a function that is marked as never returning. If control flow can ~~enter~~ exit the body of the guard statement without hitting one of those, it's a compiler error. EDIT: Exit the body of the guard statement, not enter.
    - latexr 4y ago
      > ~~enter~~ I get you’re going for the non-standard markdown strike through, but that looks confusing and calls attention to something you meant to remove. You can (well, could) remove the word when editing.
      - pdpi 4y ago
        It is possibly the one Markdown feature I'd like HN to have. I use it all the time on Reddit to correct my comments without making replies look like nonsense.
pdpi 4y ago
> And I certainly don't need the levels of abstraction that design patterns or Haskell typeclasses demand. I think it's fair to say that AbstractSingletonProxyFactoryBean[0] is something of an abomination, but it's important to avoid throwing the baby out with the bathwater. Some of the Go4 patterns like Command, Observer, Visitor, and Iterator are literally all over the place and you have to actively go out of your way to avoid writing them. Likewise, Haskell type classes aren't something you're supposed to be implementing yourself all over the place in your application. They're very high bang-for-buck things you implement in libraries. The equivalent to implementing iterators for your collections, or AutoCloseable on resource-like java classes. 0. https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring-framework/docs/current/javadoc...
pydry 4y ago
>I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. Well, yeah, coz that's worse. It decreases code cohesion (especially when those functions are stuck in files far away) and to little appreciable benefit. >First, because there are no universal code principles I think there are and good developers have a spidey sense about what they are and will usually agree but we've yet to culturally agree on what they are as an industry. Moreover, some literature on the topic (e.g. Robert Martin) is very, very wrong.
DeathArrow 4y ago
For some people esthetic considerations, philosophical considerations trumps usefulness, functionality, productivity the ease of coding, the ease of reading and understanding code. They rather have clean, SOLID, DRY, design patterns than easy, fast, productive code.
dkarl 4y ago
I see it more as a tick-tock pendulum swing. A principle is neglected, then comes roaring back because of the glaring need for it. It becomes overused, fetishized, and popularized in warped ways. Then the "accepted design principle considered harmful" articles appear, and the pendulum starts to swing back the other way. What we have to keep in mind is that the needs of whatever codebase we're working on might be out of sync with fashion. For example, I've been relishing the recent push-back against DRY, because I think it's over-applied in damaging ways, but the main codebase I've been working on for the last year needs more application of DRY, not less.
watwut 4y ago
> I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. I actually would not. I do not want to have to read every detail of each condition or formula on the first pass. I want to see high level gist of what is supposed to happen - high level algorithm. Plus, I like when variables have clearly limited scopes.
hk1337 4y ago
We have a tendency sometimes to prematurely abstract pieces of code. I am okay with copy-pasting code but after the second or third copy-paste, you should probably at least consider asking, “Should I abstract this into its own function?”
- WorldMaker 4y ago
  One way this is formulated is the "Rule of 3 for Abstractions": One copy of something is YAGNI. You aren't going to need it (an abstraction). Two copies of something are coincidence. It's fine to copy and paste and leave it that way. Three copies of something are finally a pattern. At least three copies are when you start to really see what sort of abstraction that you need to handle the pattern.
908B64B197 4y ago
> And second, because it's very easy to go from a good guideline to a dogma. All you need is a few people to misinterpret your guidelines. Heck, a lot of people haven't even read the guidelines. They just parrot what someone else paraphrased on Twitter. Another issue that's never explicitely mentionned is the vastly different calibers of programmers and engineers in the field. I'm pretty sure John Carmack, Linus Torvald or Donald Knuth's definition of "good code" is quite different than $BODY_SHOP_RESSOURCE_1389's.
noodle 4y ago
I personally take a more pragmatic approach, though perhaps its "post-modern". How well-architected, tested, groomed, etc my code tends to be is proportional to the confidence the business has in the problem space. If I have a detailed, firm spec that I know won't change at all, I'd spend some time planning and then build a DRYed up, abstracted, well-tested, etc solution. I know the solution is going to be sticking around for a while, more or less, so it makes sense to devote the effort to build a solid foundation. If the thing I'm building is squishy, looking for heavy user feedback, will likely be iterated on quickly (i.e., very agile manifesto agile), I won't spend the overhead time for those things. There's a nonzero chance the code ends up in the trashcan, and the most important thing is to ship something and get feedback from real customers. You later go back and clean it up, based on the growing confidence in the permanence of that feature.

agentultra 4y ago

> I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. And I certainly don't need the levels of abstraction that design patterns or Haskell typeclasses demand. I’d say it’s pretty subjective. I’m the opposite. I can’t read functions that are a hundred lines long with a dozen bound variables and half a dozen branches and early exits. That’s not easy to read and it requires keeping a notepad with you to figure out the control flow. I much prefer short definitions with clear logic. Leave the semantics to the edges of the program where it matters. It’s easier to reason about using substitution and algebraic manipulation. Don’t get me wrong though, I write my fair share of C code and low level drivers. For that though I tend to use a higher level language to work out the logic. My business isn’t writing code. That’s the boring part. It’s solving the problems that is interesting. But that’s the funny thing. Regardless we could both solve the same problems in our own ways and more often than not it will be good enough. After twenty years and hoping for another twenty… I guess I’ve learned that what matters is that you can get along with your team and read each other’s code. Styles come and go and don’t matter that much.

000ooo000 4y ago
I'm with you re. short functions. Setting boundaries around code, i.e. scope, and giving that behaviour a well-defined signature (i.e. a descriptive name, what it needs, and what it gives back) makes it easier to reason about the overall functionality. Giant functions reduce my confidence that any given change isn't going to introduce a problem. I like to imagine each execution path through a function as a piece of string. The fewer strings, the fewer kinks, and the less string overall, the easier it is for my monkey brain to handle most of the time. Yes this is 'cyclomatic complexity', but strings are nicer visually :)
wruza 4y ago
That’s not easy to read and it requires keeping a notepad with you to figure out the control flow. It does require a notepad as well when a five-page long function gets smeared across three “services”, five files and tens of functions, each doing a couple lines of code. Leave the semantics to the edges of the program where it matters Agreed. But when I meet this highly-structured code (and get confused), it’s usually split not across semantics, but across some random undocumented ideas about reuse, undeclared abstractions, highly indirect flow control, etc. And all of that named as if it was a most bizarre naming contest. So that instead of a little hairy idea you get a convoluted irrational multi-plane horror to deal with.
- agentultra 4y ago
  Yes, I understand. In highly procedural code the unprincipled combination of functions results in layers of indirection which do not make the code any easier to understand. It requires discipline to achieve what I call here, principled combination: that the combination of functions follow certain laws like they do in mathematics. In many programming languages it requires discipline because the type systems and the programming languages are not constructed in such a way as to uphold these laws for you. You, the programmer, have to enforce these laws on your code. That is why, when I'm writing something in C, I will some times prototype my design in a higher-level language first and translate that into C code. The higher level language is more principled and helps me catch errors in the design and development stage before I've made a mess of things. I don't always do it that way but it tends to work the best when I can get it to.

tombert 4y ago

One opinion that seems to have completely changed since I first learned is about having a single `return` in my function. It was hammered into my when I first learned that you should only ever have one exit in your code, anything else is bad practice. Fast forward about 11 years, and people realize that having a million nested if statements and matching else blocks is actually absurdly unreadable; much better to just return early, avoid nesting, and break the "only one exit" pattern.

p1necone 4y ago
I'm big fan of separating functions into validation and logic using early returns: function doSomeStuff(input) { if(someInvariantIsUnsatisfied(input)) { return Error; } if(someOtherInvariantIsUnsatisfied(input)) { return Error; } //do stuff return result; }
- Jtsummers 4y ago
  The term for that is a "guard". Swift took it literally and introduced guard statements which force you to terminate the containing scope (return, throw, continue, break) or call a function that is marked as never returning. If control flow can ~~enter~~ exit the body of the guard statement without hitting one of those, it's a compiler error. EDIT: Exit the body of the guard statement, not enter.
  - latexr 4y ago
    > ~~enter~~ I get you’re going for the non-standard markdown strike through, but that looks confusing and calls attention to something you meant to remove. You can (well, could) remove the word when editing.
    - pdpi 4y ago
      It is possibly the one Markdown feature I'd like HN to have. I use it all the time on Reddit to correct my comments without making replies look like nonsense.

pdpi 4y ago

> And I certainly don't need the levels of abstraction that design patterns or Haskell typeclasses demand. I think it's fair to say that AbstractSingletonProxyFactoryBean[0] is something of an abomination, but it's important to avoid throwing the baby out with the bathwater. Some of the Go4 patterns like Command, Observer, Visitor, and Iterator are literally all over the place and you have to actively go out of your way to avoid writing them. Likewise, Haskell type classes aren't something you're supposed to be implementing yourself all over the place in your application. They're very high bang-for-buck things you implement in libraries. The equivalent to implementing iterators for your collections, or AutoCloseable on resource-like java classes. 0. https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring-framework/docs/current/javadoc...

pydry 4y ago

>I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. Well, yeah, coz that's worse. It decreases code cohesion (especially when those functions are stuck in files far away) and to little appreciable benefit. >First, because there are no universal code principles I think there are and good developers have a spidey sense about what they are and will usually agree but we've yet to culturally agree on what they are as an industry. Moreover, some literature on the topic (e.g. Robert Martin) is very, very wrong.

DeathArrow 4y ago

For some people esthetic considerations, philosophical considerations trumps usefulness, functionality, productivity the ease of coding, the ease of reading and understanding code. They rather have clean, SOLID, DRY, design patterns than easy, fast, productive code.

dkarl 4y ago

I see it more as a tick-tock pendulum swing. A principle is neglected, then comes roaring back because of the glaring need for it. It becomes overused, fetishized, and popularized in warped ways. Then the "accepted design principle considered harmful" articles appear, and the pendulum starts to swing back the other way. What we have to keep in mind is that the needs of whatever codebase we're working on might be out of sync with fashion. For example, I've been relishing the recent push-back against DRY, because I think it's over-applied in damaging ways, but the main codebase I've been working on for the last year needs more application of DRY, not less.

watwut 4y ago

> I'd much rather read one function top to bottom than have to jump into 7 nested function calls that are only called once. I actually would not. I do not want to have to read every detail of each condition or formula on the first pass. I want to see high level gist of what is supposed to happen - high level algorithm. Plus, I like when variables have clearly limited scopes.

hk1337 4y ago

We have a tendency sometimes to prematurely abstract pieces of code. I am okay with copy-pasting code but after the second or third copy-paste, you should probably at least consider asking, “Should I abstract this into its own function?”

WorldMaker 4y ago
One way this is formulated is the "Rule of 3 for Abstractions": One copy of something is YAGNI. You aren't going to need it (an abstraction). Two copies of something are coincidence. It's fine to copy and paste and leave it that way. Three copies of something are finally a pattern. At least three copies are when you start to really see what sort of abstraction that you need to handle the pattern.

908B64B197 4y ago

> And second, because it's very easy to go from a good guideline to a dogma. All you need is a few people to misinterpret your guidelines. Heck, a lot of people haven't even read the guidelines. They just parrot what someone else paraphrased on Twitter. Another issue that's never explicitely mentionned is the vastly different calibers of programmers and engineers in the field. I'm pretty sure John Carmack, Linus Torvald or Donald Knuth's definition of "good code" is quite different than $BODY_SHOP_RESSOURCE_1389's.

noodle 4y ago

I personally take a more pragmatic approach, though perhaps its "post-modern". How well-architected, tested, groomed, etc my code tends to be is proportional to the confidence the business has in the problem space. If I have a detailed, firm spec that I know won't change at all, I'd spend some time planning and then build a DRYed up, abstracted, well-tested, etc solution. I know the solution is going to be sticking around for a while, more or less, so it makes sense to devote the effort to build a solid foundation. If the thing I'm building is squishy, looking for heavy user feedback, will likely be iterated on quickly (i.e., very agile manifesto agile), I won't spend the overhead time for those things. There's a nonzero chance the code ends up in the trashcan, and the most important thing is to ship something and get feedback from real customers. You later go back and clean it up, based on the growing confidence in the permanence of that feature.