Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Observation #2

Open
wstomv opened this issue Dec 10, 2020 · 2 comments
Open

Observation #2

wstomv opened this issue Dec 10, 2020 · 2 comments

Comments

@wstomv
Copy link

wstomv commented Dec 10, 2020

I miss the heading Robustness, though some of the relevant items can be found under other headings. What do you think?

@mgreiler
Copy link
Owner

Interesting thought. Which items would you re-assign to this section, and which new ones would you add?

@wstomv
Copy link
Author

wstomv commented Dec 10, 2020

Good question (and good strategy to play this back to me).

For me, robustness of code concerns whether it will not misbehave when used outside its intended purpose (e.g. call a function when its precondition is not met). So, a first question a developer should ask is whether the code needs to be robust (see below). A second question -- if robustness is desirable -- is how to achieve it. And this typically is a cross-cutting (hence architectural) concern. Any larger piece of software should have a strategy to make things robust in a consistent way, often involving a separate module (e.g. for error handling/logging).

Related areas:

  • Logic Errors and Bugs, especially the second item.
  • Error Handling and Logging (I probably would merge that into Robustness, or just add the Robustness header there).
  • Security (but those are all formulated specifically for security, though the last two items are clearly related to robustness). I'd keep these as is.

When a function need/must not be made robust:

  • When checking its precondition is too costly. Example: A function that does a binary search on a sorted array expects the input array to be sorted, but checking that sortedness condition would be linear in the length of the array, whereas the purpose of a binary search is to get a logarithmic solution. (An alternative in this particular case, is to change the postcondition, so that sortedness is no longer a precondition. But this is a rather technical point, having to do with the fact that termination of binary search does not need the array to be sorted.)
  • When the function must be as fast as possible, and is called only locally where it is clear that its precondition is satisfied. I.e., it is not on some external API.

Possible extra items for Robustness:

  • Is the code robust? If not, is the reason documented?
  • Has robustness been achieved consistent with the overall software architecture?

But I leave it to you to consider whether/how you want to incorporate robustness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants