4 ms·

What the author is missing is that easy to read/reason/understand about is within the context of making a change to the code to fix a bug, add a feature or make

What the author is missing is that easy to read/reason/understand about is within the context of making a change to the code to fix a bug, add a feature or make some non-functional improvement to it. This is what most of the "easy to read" articles forget. Show me why it is easier to fix a bug, add a feature or make a non-functional improvement to the code with their style than without. For example, if you've extracted something into its own function, are you then sharing this function and using it in other places as well? If you then change the body of that function, are you now possibly breaking other parts of the code that relied on its old behavior? If you've introduced a local mutable variable in between two lines, are you then mutating that variable prior/later? Is the query_params different at the end of the function then in the middle? Can you safely use it again? How easily can you now introduce new behavior before, in the middle, after, and anywhere in-between? When you modify the behavior to fix a bug, add a feature or make a non-functional improvement, is it an isolated change? How many tests break? Did it require major refactoring to make or very few things had to change? How easy was it to add a test for your new behavior? Was it easy to find the most appropriate place in the code to make the change? Etc. Sure sometimes maybe you just read code for the fun of understanding what it does, but almost always in practice when you're working on a code base, you only care to understand and reason about the code because you're looking to deliver that next sprint task that involves changing something about it. I wish more people focused on "easy to change/modify" then simply on "easy to read/understand".

edgyquant 4y ago
If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else.
- sidlls 4y ago
  Unless the test cases are incomplete. Or the CI jobs are configured to run tests independently and off-cadence so that code that would break is tested after a merge. Or the tests have a bug in them. And so on.
- Supermancho 4y ago
  > If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else. "should" is a word loaded with authority. Why? If you believe a unit tests is for turning an impure function into a pure function (so you can just test what it's doing and no other effects), then in many cases tweaking will break existing unit tests. If the function exists, it's assumed it's used by more than the tests for it. Changing the signature or even the internal dependencies necessarily breaks the known contracts with other units.
  - chii 4y ago
    > breaks the known contracts with other units. which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.
    - Supermancho 4y ago
      Indeed on both counts. This is a demonstration of why a code change may seem simple in theory, but when you actually do it, you can see all the side effects that you didn't consider when estimating. This is one of the many ways that estimation without looking at existing code, can be completely off...not to say it will be right-on when estimating and looking at code. I have worked a company with 8 hour planning, where every single change is by committee while looking at existing code. Mercifully, this methodology didn't last more than a few months.
  - edgyquant 4y ago
    No it doesn’t and I’d hate to have you working on my team with this mindset.
    - Supermancho 4y ago
      > even the internal dependencies necessarily breaks the known contracts with other units The implication is that there are unit tests for those dependencies as well. Changing the signature used for them, breaks the same contracts as a wrapping function signature change. Ofc, you may already have tests to cover alternate signatures (overloading, et al) but conceptually it's the same pitfall.
michaelcampbell 4y ago
> For example, if you've extracted something into its own function, are you then sharing this function and using it in other places as well? If you then change the body of that function, are you now possibly breaking other parts of the code that relied on its old behavior? You absolutely are. Which is why I think that DRY was pushed too hard, and for the wrong reasons. Everyone said "you only have to change it once!" rather than "consider how many callers depend on this". There's a reason the "rule of 3" came around; and those reasons I've found were mostly experience and empirically based.

edgyquant 4y ago

If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else.

sidlls 4y ago
Unless the test cases are incomplete. Or the CI jobs are configured to run tests independently and off-cadence so that code that would break is tested after a merge. Or the tests have a bug in them. And so on.
Supermancho 4y ago
> If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else. "should" is a word loaded with authority. Why? If you believe a unit tests is for turning an impure function into a pure function (so you can just test what it's doing and no other effects), then in many cases tweaking will break existing unit tests. If the function exists, it's assumed it's used by more than the tests for it. Changing the signature or even the internal dependencies necessarily breaks the known contracts with other units.
- chii 4y ago
  > breaks the known contracts with other units. which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.
  - Supermancho 4y ago
    Indeed on both counts. This is a demonstration of why a code change may seem simple in theory, but when you actually do it, you can see all the side effects that you didn't consider when estimating. This is one of the many ways that estimation without looking at existing code, can be completely off...not to say it will be right-on when estimating and looking at code. I have worked a company with 8 hour planning, where every single change is by committee while looking at existing code. Mercifully, this methodology didn't last more than a few months.
- edgyquant 4y ago
  No it doesn’t and I’d hate to have you working on my team with this mindset.
  - Supermancho 4y ago
    > even the internal dependencies necessarily breaks the known contracts with other units The implication is that there are unit tests for those dependencies as well. Changing the signature used for them, breaks the same contracts as a wrapping function signature change. Ofc, you may already have tests to cover alternate signatures (overloading, et al) but conceptually it's the same pitfall.

michaelcampbell 4y ago

> For example, if you've extracted something into its own function, are you then sharing this function and using it in other places as well? If you then change the body of that function, are you now possibly breaking other parts of the code that relied on its old behavior? You absolutely are. Which is why I think that DRY was pushed too hard, and for the wrong reasons. Everyone said "you only have to change it once!" rather than "consider how many callers depend on this". There's a reason the "rule of 3" came around; and those reasons I've found were mostly experience and empirically based.