7 ms·

I'd love to see a similar list for software engineering. - if your code isn't important enough to be tested, it's not important to be written - every function

I'd love to see a similar list for software engineering. - if your code isn't important enough to be tested, it's not important to be written - every function must fit a single screen

jumperjoey 7y ago
'every function must fit a single screen' wow, that's an annoying one
usea 7y ago
- if your code isn't important enough to be tested, it's not important to be written Does this rule cover all code? Do your tests, which are code themselves, not need their own tests? If not, what is special about a test that you know it's correct, when there is no faith in in non-test code? Is it possible to write your program entirely out of the special "test" code, so that it's always correct and doesn't need to be tested?
- Waterluvian 7y ago
  This is the danger of dumb rules like this. Nothing's universally true. Part of what an engineer is paid for is knowing what should be tested to what extent.
- AlexTWithBeard 7y ago
  Well, the cliche apparently tries to cover all the code, which, as you correctly said, is non-practical. The problem is that, like all other cliches, it sounds very convincing and it may take quite some time for the young inexperienced mind to rebuff it.
- mLuby 7y ago
  My tests run during tests, so they automatically have 100% test coverage. :D
  - plorkyeran 7y ago
    It's not all that uncommon to have test code which is never actually run. Usually just because of disabled tests or leftover helper functions that are no longer used, but sometimes due to bugs in the tests themselves. Turning on code coverage tracking for the test code itself can sometimes reveal some interesting things.
  - DonHopkins 7y ago
    Always write recursive code. It tests itself!
- swiftcoder 7y ago
  One finds a truly surprising number of bugs in tests and test frameworks. So yes, your tests need tests.
  - gmueckl 7y ago
    A classic case of this bug is "I don't think this test case is doing what you think it is doing". I've produced my share of test cases that were elaborate duds.
- mikeash 7y ago
  You don’t necessarily need automated tests, but you absolutely do need to test your tests. With any new test, I always verify that 1) it passes with the fix 2) it fails without the fix. Many programmers skip step 2 and it’s a good way to end up with tests that don’t test what you think they do.
- megaremote 7y ago
  > Do your tests, which are code themselves, not need their own tests? The tests of the tests is your original code. They are testing each other.
cuddlecake 7y ago
Everytime my co-worker tries to mention the "Pareto-Principle" (a.k.a. "Please let's not waste time on this, because it's frontend and I don't care about frontend") and "Single Source of Truth" (a.k.a. "let's expose our DB as directly as possible"), my soul barfs.
- zachrose 7y ago
  I’ve used “single source of truth” to explain what I like about Redux/the Elm Architecture. Yeah it shouldn’t mean anything about access or indirection but it’s still a decent idea, no?
  - haggy 7y ago
    Depends on what your designing. If you're working on highly distributed, microservice based backends then single sources of truth can quickly become a serious bottleneck. Check out Event Sourcing if you're not already familiar with it. This is essentially a pattern where each area of your domain maintains its own view of the data it needs through immutable "facts" (events). In this case you could say the source of truth is your persistent event log but that doesn't hold true if you're not using one (not a great idea but hey I'm not here to judge)
    - cuddlecake 7y ago
      Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a team of 7 who thinks this is terrible.
      - pgwhalen 7y ago
        Can you describe what you mean by indirectly?
        Nimelrian 7y ago
        Not the person you're responding to, but I was on a team which probably did the same thing. Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that. A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer. Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.
jasonhansel 7y ago
I could add an entire 10-page rant about people who insist on the Liskov substitution principle.
- AlexTWithBeard 7y ago
  Whether square should inherit from rectangle?
- mikeash 7y ago
  I never heard of the LSP being at all questionable. Can you elaborate?
  - jasonhansel 7y ago
    Not without writing that 10-page rant....
sys_64738 7y ago
In other words, untested code is broken code.
- bdcravens 7y ago
  Except almost no code is untested. It's just typically not tested via $approvedProcess
  - mikeash 7y ago
    In my experience, error handling code is often completely untested by any means.
damontal 7y ago
Single screen eh? Is that why I see all the devs at the office with their screens turned sideways?
tome 7y ago
You can write bad code in any language Imperative languages are the best match for the underlying hardware Use the right tool for the job A language is just another tool in your toolbox
DonHopkins 7y ago
How about fitting functions to the problems they solve, not the screens they're displayed on? And do you mean a wide screen retina monitor with a tiny font? Or 24x40 Apple ][ screens of FORTH code, where you leave out comments and put everything on one line just to make it fit? https://donhopkins.com/home/archive/forth/supdup.f https://donhopkins.com/home/archive/forth/supdup.f Trying to fit a function on one page is antithetical to so many other much more important goals, like readability and cohesiveness and documentation. I prefer code that uses white space and blank lines liberally to group and align related things together, and break apart separate steps, with complex calculations broken apart using intermediate results stored in descriptively named variables, and as many comments as necessary, even if it doesn't all fit on one page. https://donhopkins.com/home/archive/forth/alloc.f https://donhopkins.com/home/archive/forth/alloc.f
flukus 7y ago
> if your code isn't important enough to be tested, it's not important to be written The majority of code that delivers this page to you (web server, OS's, browser, networks, drivers) in a readable way has no unit tests and most of it has very little QA. Presumably you think you shouldn't be able to read this page? > every function must fit a single screen A policy by assholes that don't do maintenance. Diving through a million little functions is a lot harder than fewer bigger ones (up to a point). Parroting this show a complete lack of understanding of why long functions can be bad, it's the state not the scrolling.

I'd love to see a similar list for software engineering. - if your code isn't important enough to be tested, it's not important to be written - every function must fit a single screen

jumperjoey 7y ago

'every function must fit a single screen' wow, that's an annoying one

usea 7y ago

- if your code isn't important enough to be tested, it's not important to be written Does this rule cover all code? Do your tests, which are code themselves, not need their own tests? If not, what is special about a test that you know it's correct, when there is no faith in in non-test code? Is it possible to write your program entirely out of the special "test" code, so that it's always correct and doesn't need to be tested?

Waterluvian 7y ago
This is the danger of dumb rules like this. Nothing's universally true. Part of what an engineer is paid for is knowing what should be tested to what extent.
AlexTWithBeard 7y ago
Well, the cliche apparently tries to cover all the code, which, as you correctly said, is non-practical. The problem is that, like all other cliches, it sounds very convincing and it may take quite some time for the young inexperienced mind to rebuff it.
mLuby 7y ago
My tests run during tests, so they automatically have 100% test coverage. :D
- plorkyeran 7y ago
  It's not all that uncommon to have test code which is never actually run. Usually just because of disabled tests or leftover helper functions that are no longer used, but sometimes due to bugs in the tests themselves. Turning on code coverage tracking for the test code itself can sometimes reveal some interesting things.
- DonHopkins 7y ago
  Always write recursive code. It tests itself!
swiftcoder 7y ago
One finds a truly surprising number of bugs in tests and test frameworks. So yes, your tests need tests.
- gmueckl 7y ago
  A classic case of this bug is "I don't think this test case is doing what you think it is doing". I've produced my share of test cases that were elaborate duds.
mikeash 7y ago
You don’t necessarily need automated tests, but you absolutely do need to test your tests. With any new test, I always verify that 1) it passes with the fix 2) it fails without the fix. Many programmers skip step 2 and it’s a good way to end up with tests that don’t test what you think they do.
megaremote 7y ago
> Do your tests, which are code themselves, not need their own tests? The tests of the tests is your original code. They are testing each other.

cuddlecake 7y ago

Everytime my co-worker tries to mention the "Pareto-Principle" (a.k.a. "Please let's not waste time on this, because it's frontend and I don't care about frontend") and "Single Source of Truth" (a.k.a. "let's expose our DB as directly as possible"), my soul barfs.

zachrose 7y ago
I’ve used “single source of truth” to explain what I like about Redux/the Elm Architecture. Yeah it shouldn’t mean anything about access or indirection but it’s still a decent idea, no?
- haggy 7y ago
  Depends on what your designing. If you're working on highly distributed, microservice based backends then single sources of truth can quickly become a serious bottleneck. Check out Event Sourcing if you're not already familiar with it. This is essentially a pattern where each area of your domain maintains its own view of the data it needs through immutable "facts" (events). In this case you could say the source of truth is your persistent event log but that doesn't hold true if you're not using one (not a great idea but hey I'm not here to judge)
  - cuddlecake 7y ago
    Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a team of 7 who thinks this is terrible.
    - pgwhalen 7y ago
      Can you describe what you mean by indirectly?
      - Nimelrian 7y ago
        Not the person you're responding to, but I was on a team which probably did the same thing. Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that. A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer. Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.

jasonhansel 7y ago

I could add an entire 10-page rant about people who insist on the Liskov substitution principle.

AlexTWithBeard 7y ago
Whether square should inherit from rectangle?
mikeash 7y ago
I never heard of the LSP being at all questionable. Can you elaborate?
- jasonhansel 7y ago
  Not without writing that 10-page rant....

sys_64738 7y ago

In other words, untested code is broken code.

bdcravens 7y ago
Except almost no code is untested. It's just typically not tested via $approvedProcess
- mikeash 7y ago
  In my experience, error handling code is often completely untested by any means.

damontal 7y ago

Single screen eh? Is that why I see all the devs at the office with their screens turned sideways?

tome 7y ago

You can write bad code in any language Imperative languages are the best match for the underlying hardware Use the right tool for the job A language is just another tool in your toolbox

DonHopkins 7y ago

How about fitting functions to the problems they solve, not the screens they're displayed on? And do you mean a wide screen retina monitor with a tiny font? Or 24x40 Apple ][ screens of FORTH code, where you leave out comments and put everything on one line just to make it fit? https://donhopkins.com/home/archive/forth/supdup.f https://donhopkins.com/home/archive/forth/supdup.f Trying to fit a function on one page is antithetical to so many other much more important goals, like readability and cohesiveness and documentation. I prefer code that uses white space and blank lines liberally to group and align related things together, and break apart separate steps, with complex calculations broken apart using intermediate results stored in descriptively named variables, and as many comments as necessary, even if it doesn't all fit on one page. https://donhopkins.com/home/archive/forth/alloc.f https://donhopkins.com/home/archive/forth/alloc.f

flukus 7y ago

> if your code isn't important enough to be tested, it's not important to be written The majority of code that delivers this page to you (web server, OS's, browser, networks, drivers) in a readable way has no unit tests and most of it has very little QA. Presumably you think you shouldn't be able to read this page? > every function must fit a single screen A policy by assholes that don't do maintenance. Diving through a million little functions is a lot harder than fewer bigger ones (up to a point). Parroting this show a complete lack of understanding of why long functions can be bad, it's the state not the scrolling.