Edit - Software Engineering Stack Exchange

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

Rev

103

Oh my goodness this answer is it. The OP is dealing with software that has physical repercussions. The bar has been raised. The reviewer probably didn't realize this "edge case" until they got looking at the code again. And given enough time nothing is an edge case. You don't want to accidentally swing a robot's arm into someone's head (not that I know a robot arm is involved with this code).

Greg Burghardt
– Greg Burghardt

2017-02-05 13:07:56 +00:00
Commented Feb 5, 2017 at 13:07
12

Greg & Steve, this is a great example, but it's an example of a bug. It's a straightforward obscure bug. Literally "a bug", dividing by zero. When you work on robotics algorithms, it's a central idea that you think about physically-possible and not-physically-possible concepts. (If you will, "not yet" physically possible concepts, wit the current devices.) The confusion between the two developers, under discussion here, is due to them (very surprisingly) not being au fey with this paradigm. Their whole team has sever problems if, the more senior dudes have not embedded that paradigm.

Fattie
– Fattie

2017-02-05 13:25:09 +00:00
Commented Feb 5, 2017 at 13:25
11

I think there are real world examples that prove why edge cases should be covered, but this isn't one of them. The example cited is a case of using the wrong library for a task. The code for a banana should not be blindly used on an orange. It is the fault of the person who used banana code on an orange, not the person who wrote code for an orange that couldn't handle a banana. (I had to switch Apple for Banana in this analogy due to a big tech company out there...)

Origin
– Origin

2017-02-05 13:35:42 +00:00
Commented Feb 5, 2017 at 13:35
53

@JoeBlow A bug, yes, but a preventable one, one that could've been caught with additional test cases and/or code-reviews. God only knows if there was a guy there at some point saying "You know guys, I think we should validate this range..." and others going like "Don't worry about it... what could possibly go wrong with an impossible case?" If bugs are not enough proof that our logic has more gaps than we'd like, then I don't know what to say...

code_dredd
– code_dredd

2017-02-05 14:00:11 +00:00
Commented Feb 5, 2017 at 14:00
30

The point that I was trying to make is that you should not ignore test cases as never happening, extremely unlikely, etc., the standards that they were coding for called for range checking of all external input values. If that had been tested for and handled then the disaster might have been averted. Note that in Ariane 3 this was not a bug it was a failure to follow standards. When the code was reused in a different scenario if failed catastrophically while if the range of values had been clipped it would likely have failed gracefully.

Steve Barnes
– Steve Barnes

2017-02-05 15:00:07 +00:00
Commented Feb 5, 2017 at 15:00

| Show 32 more comments

Correct minor typos or mistakes
Clarify meaning without changing it
Add related resources or links
Always respect the author’s intent
Don’t use edits to reply to the author

create code fences with backticks ` or tildes ~
```
like so
```
add language identifier to highlight code
```python
def function(foo):
print(foo)
```
put returns between paragraphs
for linebreak add 2 spaces at end
_italic_ or **bold**
indent code by 4 spaces
backtick escapes `like _so_`
quote by placing > at start of line
to make links (use https whenever possible)

<https://example.com>

[example](https://example.com)

<a href="https://example.com">example</a>

formatting help »
answering help »