3 ms·

"Nobody cares about the golden path. Edge cases are our entire job." This is an obvious exaggeration; if you ignore the golden path, the code doesn't solve the

"Nobody cares about the golden path. Edge cases are our entire job." This is an obvious exaggeration; if you ignore the golden path, the code doesn't solve the problem it's meant to solve. But yes; writing reliable code is all about the edge cases. Eliminate them if you can; code for them if you can't.

AnimalMuppet 2y ago
Back in the 1970s, when I was just a high school kid reading computer magazines, I saw references to a study (I believe by IBM), that said in production code, that 70 or 80% of the lines of code was error handling; only 20% or 30% was the "golden path". I'm not sure I saw an actual reference, even then, and I certainly cannot give a reference now. Does anybody know the study in question? (I have never seen another study on the topic. Does anyone else know of one?) This was almost certainly either done in assembly or PL/I or Algol or something. Do more modern languages change it? Exceptions? Dual-track programming (options or Maybes)? Regardless of exact numbers, yes, error cases are something you have to think about all the time.
- atq2119 2y ago
  Maybe this applies to Go code? Snark aside, I am somebody who is very concerned about edge cases, but those ratios seem completely wrong to me for the kind of code I write. And perhaps one should say "corner cases" instead of "error cases". Corner cases aren't necessarily errors. What I find is that a good algorithm that is properly "in tune" with the problem space will often implicitly handle corner cases correctly. While an algorithm that was hacked together by somebody who is "coding to the test" without really understanding the problem space tends to not handle corner cases, and then the developer tries to handle them by adding if-statements to patch their handling. In the end, devoting 70% or 80% of thinking time to corner cases seems entirely plausible to me. 70% or 80% of lines of code dedicated to corner cases may be a smell.
  - wduquette 2y ago
    Depends on the kind of code. If you're automating a process, or handling large quantities of user input, for example, problem cases are everywhere. Or if you're working with a complex problem space where things can compose in unexpected ways (e.g., a language interpreter).

AnimalMuppet 2y ago

Back in the 1970s, when I was just a high school kid reading computer magazines, I saw references to a study (I believe by IBM), that said in production code, that 70 or 80% of the lines of code was error handling; only 20% or 30% was the "golden path". I'm not sure I saw an actual reference, even then, and I certainly cannot give a reference now. Does anybody know the study in question? (I have never seen another study on the topic. Does anyone else know of one?) This was almost certainly either done in assembly or PL/I or Algol or something. Do more modern languages change it? Exceptions? Dual-track programming (options or Maybes)? Regardless of exact numbers, yes, error cases are something you have to think about all the time.

atq2119 2y ago
Maybe this applies to Go code? Snark aside, I am somebody who is very concerned about edge cases, but those ratios seem completely wrong to me for the kind of code I write. And perhaps one should say "corner cases" instead of "error cases". Corner cases aren't necessarily errors. What I find is that a good algorithm that is properly "in tune" with the problem space will often implicitly handle corner cases correctly. While an algorithm that was hacked together by somebody who is "coding to the test" without really understanding the problem space tends to not handle corner cases, and then the developer tries to handle them by adding if-statements to patch their handling. In the end, devoting 70% or 80% of thinking time to corner cases seems entirely plausible to me. 70% or 80% of lines of code dedicated to corner cases may be a smell.
- wduquette 2y ago
  Depends on the kind of code. If you're automating a process, or handling large quantities of user input, for example, problem cases are everywhere. Or if you're working with a complex problem space where things can compose in unexpected ways (e.g., a language interpreter).