5 ms·

> “What’s your most controversial programming opinion?” ... What follows are twenty of the highest voted answers By definition, the highest voted answers are a

by whack 6y ago

> “What’s your most controversial programming opinion?” ... What follows are twenty of the highest voted answers By definition, the highest voted answers are also the least controversial. "Anti-establishment" and "populist" maybe. Unpopular? Certainly not. My controversial opinion is that most software tests should be integration tests that use randomized inputs. I doubt I'll get very many upvotes for that idea.

Sodaware 6y ago
A bit like how /r/unpopularopinion on Reddit ends up being full of popular sentiments.
- whimsicalism 6y ago
  > A bit like how /r/unpopularopinion on Reddit ends up being full of popular* sentiments. *racist
wolco2 6y ago
That's more popular than you think. If you said php is a pretty good language and I enjoy working with it you may get a lot of closet php developers upvoting you. A real unpopular opinion is testing is not worth the effort.
pjc50 6y ago
> most software tests should be integration tests that use randomized inputs. Good for fuzzing, bad for determining whether the output is what you expected it to be, because finding out what the output should be is .. the reason you wrote the software. I've seen this done with an automated spec translation tool that produced an unoptimised but correct H264 decoder and set of reference inputs to achieve coverage of the actual target decoder.
- loup-vaillant 6y ago
  > Good for fuzzing, bad for determining whether the output is what you expected it to be, because finding out what the output should be is .. the reason you wrote the software. The solution for this is property based tests. Outputs almost never have maximum entropy. They have invariants, and they're related to the inputs in various ways. Trivial example: authenticated encryption. The input is some random text, some random key, and some random nonce. The result is a message. One property to check is the fact that the message can successfully be decrypted with the same key, and the resulting plaintext will be the same as the random text from the beginning. Another property is that any message that is not the message you computed will fail to decrypt (assuming you pretend not to know the key when as you corrupt the message). Testing (crudely) that you can detect forgeries (or at least accidental corruptions).
SiempreViernes 6y ago
Yeah, it doesn't really read like a list of programmer flame-bait which I think is ultimately what the title implied. I mean consider this example of a "controversial opinion": > Print statements are a valid way to debug code. I'd place this about as controversial as "functions with many arguments are an ok choice". The fact that there is neither a statement about the proper indexing of arrays or which programming language to never use is clear evidence this list isn't about controversial topics.
- iab 6y ago
  I prefer functions with no inputs, quite honestly . No outputs either. Also no internal logic. To hell with variables as well.
  - Igelau 6y ago
    Excerpt from The Heart Sutra, a TL;DR translation for Programmers
  - hazeii 6y ago
    Back in the day, compiling a Fortran program that didn't do any input or output would get you a "Program is trivial" message (and nothing else).
gregmac 6y ago
> My controversial opinion is that most software tests should be integration tests that use randomized inputs. I doubt I'll get very many upvotes for that idea. Probably not, but largely because you used the word "randomized". One of the most annoying things to deal with in a CI workflow is flaky tests (where something unchanged will randomly fail, or re-running will result in a different outcome). The most common way I've seen this happen is with an external dependency like using a database server or calling a 3rd party API. The failure is usually temporary (eg: timeout) and so it's a false negative. This trains developers to do a lazy workaround: re-run the build until it passes. True "randomized" data has the possibility that you get all kinds of flaky tests, but that they cause false positives: the failures are legitimate, passing is not. Pseudo-randomized [1] data is a different story (see: fuzzing [2]), because you still have predictable tests -- the difference is a human doesn't have to think up thousands of test cases. I'd say it's also important to add specific test cases when you do find a specific type of failure, just to be sure that always gets tested. I think if you call it "pseudo-random" or "fuzz testing" you'll find it's much less controversial. [1] https://en.wikipedia.org/wiki/Pseudorandomness https://en.wikipedia.org/wiki/Pseudorandomness [2] https://en.wikipedia.org/wiki/Fuzzing https://en.wikipedia.org/wiki/Fuzzing
- loup-vaillant 6y ago
  > One of the most annoying things to deal with in a CI workflow is flaky tests (where something unchanged will randomly fail, or re-running will result in a different outcome). Just records the input whenever the test fails, and have an option to re-run a test, with those inputs. The tests are still flaky but it doesn't matter if we can reproduce the results. You don't even have to record all inputs. You could just use a random seed, and record the seed at each run. Test become deterministic again simply by fixing the seed (typically to a value that caused the previous run to fail).
  - gregmac 6y ago
    Using a seed with the "random" is exactly how you get to pseudo-random, which gives the same sequence everytime, and is absolutely fine for tests. If you want to have the build (test) result feedback to save the input, that's an ok goal but I think it's hard to pull off: now you have your build making commits to source control (causing another build), or you have test data stored somewhere else not in source (when really, it should be part of source).
dang 6y ago
> By definition, the highest voted answers are also the least controversial That's not correct because it leaves out motivation to vote. Imagine a controversial question where, say, 1/3 of the population feels super strongly and is likeliest to vote on it. Their view will shoot to the top. Then the other 2/3 will go "wtf is wrong with this community".
sidlls 6y ago
It depends on the context I think. Library code (most library code anyway) should have unit tests covering the public api at minimum. Unit tests might also be a good idea for interpreted/highly dynamic languages like Python, if only because you need to implement something like a compiler’s checks on signatures and arguments by hand in order to keep non trivial applications sane. But generally I’m with you. Unit testing is overused and often makes code harder to read maintain and build on. That’s aside from it not providing information most unit test advocates think it provides.
galangalalgol 6y ago
Yeah, I vehemently agree with every single opinion listed. I would add that comments aren't just extra, they are often outright lies.

by whack 6y ago

Sodaware 6y ago

A bit like how /r/unpopularopinion on Reddit ends up being full of popular sentiments.

whimsicalism 6y ago
> A bit like how /r/unpopularopinion on Reddit ends up being full of popular* sentiments. *racist

wolco2 6y ago

That's more popular than you think. If you said php is a pretty good language and I enjoy working with it you may get a lot of closet php developers upvoting you. A real unpopular opinion is testing is not worth the effort.

pjc50 6y ago

> most software tests should be integration tests that use randomized inputs. Good for fuzzing, bad for determining whether the output is what you expected it to be, because finding out what the output should be is .. the reason you wrote the software. I've seen this done with an automated spec translation tool that produced an unoptimised but correct H264 decoder and set of reference inputs to achieve coverage of the actual target decoder.

loup-vaillant 6y ago
> Good for fuzzing, bad for determining whether the output is what you expected it to be, because finding out what the output should be is .. the reason you wrote the software. The solution for this is property based tests. Outputs almost never have maximum entropy. They have invariants, and they're related to the inputs in various ways. Trivial example: authenticated encryption. The input is some random text, some random key, and some random nonce. The result is a message. One property to check is the fact that the message can successfully be decrypted with the same key, and the resulting plaintext will be the same as the random text from the beginning. Another property is that any message that is not the message you computed will fail to decrypt (assuming you pretend not to know the key when as you corrupt the message). Testing (crudely) that you can detect forgeries (or at least accidental corruptions).

SiempreViernes 6y ago

Yeah, it doesn't really read like a list of programmer flame-bait which I think is ultimately what the title implied. I mean consider this example of a "controversial opinion": > Print statements are a valid way to debug code. I'd place this about as controversial as "functions with many arguments are an ok choice". The fact that there is neither a statement about the proper indexing of arrays or which programming language to never use is clear evidence this list isn't about controversial topics.

iab 6y ago
I prefer functions with no inputs, quite honestly . No outputs either. Also no internal logic. To hell with variables as well.
- Igelau 6y ago
  Excerpt from The Heart Sutra, a TL;DR translation for Programmers
- hazeii 6y ago
  Back in the day, compiling a Fortran program that didn't do any input or output would get you a "Program is trivial" message (and nothing else).

gregmac 6y ago

> My controversial opinion is that most software tests should be integration tests that use randomized inputs. I doubt I'll get very many upvotes for that idea. Probably not, but largely because you used the word "randomized". One of the most annoying things to deal with in a CI workflow is flaky tests (where something unchanged will randomly fail, or re-running will result in a different outcome). The most common way I've seen this happen is with an external dependency like using a database server or calling a 3rd party API. The failure is usually temporary (eg: timeout) and so it's a false negative. This trains developers to do a lazy workaround: re-run the build until it passes. True "randomized" data has the possibility that you get all kinds of flaky tests, but that they cause false positives: the failures are legitimate, passing is not. Pseudo-randomized [1] data is a different story (see: fuzzing [2]), because you still have predictable tests -- the difference is a human doesn't have to think up thousands of test cases. I'd say it's also important to add specific test cases when you do find a specific type of failure, just to be sure that always gets tested. I think if you call it "pseudo-random" or "fuzz testing" you'll find it's much less controversial. [1] https://en.wikipedia.org/wiki/Pseudorandomness https://en.wikipedia.org/wiki/Pseudorandomness [2] https://en.wikipedia.org/wiki/Fuzzing https://en.wikipedia.org/wiki/Fuzzing

loup-vaillant 6y ago
> One of the most annoying things to deal with in a CI workflow is flaky tests (where something unchanged will randomly fail, or re-running will result in a different outcome). Just records the input whenever the test fails, and have an option to re-run a test, with those inputs. The tests are still flaky but it doesn't matter if we can reproduce the results. You don't even have to record all inputs. You could just use a random seed, and record the seed at each run. Test become deterministic again simply by fixing the seed (typically to a value that caused the previous run to fail).
- gregmac 6y ago
  Using a seed with the "random" is exactly how you get to pseudo-random, which gives the same sequence everytime, and is absolutely fine for tests. If you want to have the build (test) result feedback to save the input, that's an ok goal but I think it's hard to pull off: now you have your build making commits to source control (causing another build), or you have test data stored somewhere else not in source (when really, it should be part of source).

dang 6y ago

> By definition, the highest voted answers are also the least controversial That's not correct because it leaves out motivation to vote. Imagine a controversial question where, say, 1/3 of the population feels super strongly and is likeliest to vote on it. Their view will shoot to the top. Then the other 2/3 will go "wtf is wrong with this community".

sidlls 6y ago

It depends on the context I think. Library code (most library code anyway) should have unit tests covering the public api at minimum. Unit tests might also be a good idea for interpreted/highly dynamic languages like Python, if only because you need to implement something like a compiler’s checks on signatures and arguments by hand in order to keep non trivial applications sane. But generally I’m with you. Unit testing is overused and often makes code harder to read maintain and build on. That’s aside from it not providing information most unit test advocates think it provides.

galangalalgol 6y ago

Yeah, I vehemently agree with every single opinion listed. I would add that comments aren't just extra, they are often outright lies.