5 ms·

I don't trust my future self that I'll start feeding in bad data. Of course there are some boundaries, but not too deep. I've started more of defensive coding

by jve 5y ago

I don't trust my future self that I'll start feeding in bad data. Of course there are some boundaries, but not too deep. I've started more of defensive coding when I've read that for a software I forgot how it called - there was security audit which find no important security flaws. Because their ideology was to not trust the input, even if its your input. Today your assumptions are correct, tomorrow, because of changes, they can be incorrect. I'll post link here if I find it. I think I read it on HN few years ago. Edit: A-ha, here it is. Dovecot. HN Article: https://news.ycombinator.com/item?id=13407233 https://news.ycombinator.com/item?id=13407233 and https://wiki.mozilla.org/MOSS/Secure_Open_Source/Completed#dovecot https://wiki.mozilla.org/MOSS/Secure_Open_Source/Completed#d... > The Cure53 team were extremely impressed with the quality of the dovecot code. They wrote: "Despite much effort and thoroughly all-encompassing approach, the Cure53 testers only managed to assert the excellent security-standing of Dovecot. More specifically, only three minor security issues have been found in the codebase, thus translating to an exceptionally good outcome for Dovecot, and a true testament to the fact that keeping security promises is at the core of the Dovecot development and operations." Practices documented in source: https://github.com/dovecot/core/blob/master/doc/securecoding.txt#L13 https://github.com/dovecot/core/blob/master/doc/securecoding... > Don't rely on input validation. Maybe you missed something. Maybe someone calls your function somewhere else where you didn't originally intend it. Maybe someone makes the input validation less restrictive for some reason. Point is, it's not an excuse to cause a security hole just because input wasn't what you expected it to be. Perhaps it's just my way of dealing with "I know that input is validated". Yeah, defensive coding can get verbose, but makes me feel confident. + The NASA Coding Guidelines of states: > Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller. > The code's assertion density should average to minimally two assertions per function. /just extracting useful bits of advices from veterans

marginalia_nu 5y ago
My experience is that this type of coding actually introduces more fragility and sensitivity to change. If you validate conditions you think will be true, but do not explicitly depend upon at every level the data passes through, you'll find your application randomly blowing up when those conditions change. I think the problem boils down to a violation of separation of concerns. Defensive code inevitably concerns itself with ensuring guarantees about state that is the concern of other modules.
- Retric 5y ago
  Blowing up can be the correct answer. What should you do if a slider that ranges from 0 to 100 sends you a negative number? Fail loudly, and log it. Silently, trying to work with invalid inputs just results in bugs that people may not notice and are much harder to track down.
  - marginalia_nu 5y ago
    Right, I would say the problem exists within the slider, and not the consumer of its state. With a sensible design, you might even have the slider producing a type that makes strong guarantees about the range of its value. That moves the concern of validating the value range to that type's constructor, and removes it from the rest of the codebase.
    - jve 5y ago
      100% agree. That's why eventually I want to learn F# (currently my main driver is C#). It features more advanced type system and I love static typing, because by itself it provides nice guarantees. F# brings it further by guaranteeing specific state. I may learn F#, but I don't think I'm gonna use it in existing code base, as maintainability with fellow developers or whoever works after me is perhaps more important than F#... Not that your example cannot be achieved in C# - it can. But what I suspect F# just brings those static typing guarantees further https://fsharpforfunandprofit.com/posts/designing-for-correctness/ https://fsharpforfunandprofit.com/posts/designing-for-correc...
    - deleted 5y ago
      [deleted]
    - Retric 5y ago
      That doesn’t resolve the issue. If at runtime the physical memory associated with your strongly typed data has a negative value before the function is called either the type system checks it again which then blows up, or assumes it’s still valid and your fiction operates on faulty data. Essentially what you’re describing is automating such checks.

by jve 5y ago

marginalia_nu 5y ago

My experience is that this type of coding actually introduces more fragility and sensitivity to change. If you validate conditions you think will be true, but do not explicitly depend upon at every level the data passes through, you'll find your application randomly blowing up when those conditions change. I think the problem boils down to a violation of separation of concerns. Defensive code inevitably concerns itself with ensuring guarantees about state that is the concern of other modules.

Retric 5y ago
Blowing up can be the correct answer. What should you do if a slider that ranges from 0 to 100 sends you a negative number? Fail loudly, and log it. Silently, trying to work with invalid inputs just results in bugs that people may not notice and are much harder to track down.
- marginalia_nu 5y ago
  Right, I would say the problem exists within the slider, and not the consumer of its state. With a sensible design, you might even have the slider producing a type that makes strong guarantees about the range of its value. That moves the concern of validating the value range to that type's constructor, and removes it from the rest of the codebase.
  - jve 5y ago
    100% agree. That's why eventually I want to learn F# (currently my main driver is C#). It features more advanced type system and I love static typing, because by itself it provides nice guarantees. F# brings it further by guaranteeing specific state. I may learn F#, but I don't think I'm gonna use it in existing code base, as maintainability with fellow developers or whoever works after me is perhaps more important than F#... Not that your example cannot be achieved in C# - it can. But what I suspect F# just brings those static typing guarantees further https://fsharpforfunandprofit.com/posts/designing-for-correctness/ https://fsharpforfunandprofit.com/posts/designing-for-correc...
  - deleted 5y ago
    [deleted]
  - Retric 5y ago
    That doesn’t resolve the issue. If at runtime the physical memory associated with your strongly typed data has a negative value before the function is called either the type system checks it again which then blows up, or assumes it’s still valid and your fiction operates on faulty data. Essentially what you’re describing is automating such checks.