Skip to content

Instantly share code, notes, and snippets.

@Jbot29

Jbot29/Defensive-Programming.md

Last active June 27, 2023 18:19
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save Jbot29/076266738ce6418d1e85e8d271b821a3 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save Jbot29/076266738ce6418d1e85e8d271b821a3 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. Jbot29 revised this gist Jun 27, 2023. 1 changed file with 26 additions and 17 deletions.
    43 changes: 26 additions & 17 deletions Defensive-Programming.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,42 +1,51 @@
    # Defensive programming

    There are complicated code pieces that all interlock with each other and it is easy for bugs to occur. Often these things are difficult to test for since it is often chains of operations that need to happen and difficult to replicate
    in a testing environment, but always seem to pop up in production.
    ## Intro

    There are times when working on critical or complex systems where issues manifest but it is difficult to pin down the source.

    A set of code may write data and succeed with no issues but then another pieces comes along to read and finds that the data is wrong or incompatible. That is not horrific but when there are several actors it can be difficult to test all those scenerios and when things go south figure out which part introduced the issue.

    Functional tests can help but with complex system it is impossible to create test cases for all scenerios.

    One way I have found useful for this class of issues is called defensive programming.

    The basic idea is that at runtime parts of the code are aggressive that the data passed into it is correct. This is more than about typing. It is about validating from a logic perspective things are correct.
    ## What is it?

    By identifying things and breaking once found it is easier to find the chain that caused it. Often some code introduces a problem but only until it complete breaks things does an issue occur and it is hard to trace which part of the code
    intiated it.
    The basic idea is that at runtime parts of the code are aggressive that things are as expected.

    The problem with some systems is the change of events. Garbage flows downhill but it is is hard to tell which level introduced the breakage.
    With defensive programming the idea is that your code trusts nothing it gets and nopes out if it gets something it doesn't expect or like. With the hope that you short circuit difficult hard to trace bugs.
    This is more than about typing. It is about validating from a logic perspective things are correct.

    https://python.plainenglish.io/defensive-programming-in-python-af0266e65dfd
    This can be many things from checking that a value is in a certain range, maybe has a certain structure, even validating update operations return the what is expected, and so forth.

    Once something is a miss it is the job of that code to shut it down.

    By identifying things and breaking once found it is easier to find the chain that caused it. Often some code introduces a problem but only until it complete breaks things does an issue occur and it is hard to trace which part of the code
    intiated it.

    Benefits: Like a mix of live test cases, documents the expectations of the code
    With defensive programming the idea is that your code trusts nothing it gets and nopes out if it gets something it doesn't expect or like. With the hope that you short circuit difficult hard to trace bugs.

    Stopping errors from propagating down the stack.
    ### Other benefits

    https://docs.pydantic.dev/latest/
    Outside of just stopping the train wreck, I find that using this style of programming really makes it easy to understand a piece of code. To me defensive programming are like pratical comments.

    The best form of comments
    It also forces you to think and codify your assumptions.

    forces you to think and codify your assumptions
    ## Practice

    ### Asserts.

    Stack layer
    In Python this is easy to add just by using the assert statement.

    Each layer is just compounding earlier problems.
    assert isinstance(input_param, int)
    assert input_param in range(0,5)

    This document has a great list of different ways to use asserts.
    https://python.plainenglish.io/defensive-programming-in-python-af0266e65dfd

    ### Other tools

    Tests are great and we should have more, but the honest truth is they will never replicated the complexity of a real env with people doing crazy shit.
    Tools like Pydantic can also handle certain classes of defensive programming like data validation.

    https://docs.pydantic.dev/latest/

    Use typing, pydantic and asserts in critical areas of the code.
  2. Jbot29 revised this gist Jun 13, 2023. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion Defensive-Programming.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,7 +9,7 @@ One way I have found useful for this class of issues is called defensive program

    The basic idea is that at runtime parts of the code are aggressive that the data passed into it is correct. This is more than about typing. It is about validating from a logic perspective things are correct.

    By identifying things and breaking there it is easier to find the chain that caused it. Often some code introduces a problem but only until it complete breaks things does an issue occur and it is hard to trace which part of the code
    By identifying things and breaking once found it is easier to find the chain that caused it. Often some code introduces a problem but only until it complete breaks things does an issue occur and it is hard to trace which part of the code
    intiated it.

    The problem with some systems is the change of events. Garbage flows downhill but it is is hard to tell which level introduced the breakage.
  3. Jbot29 revised this gist Jun 13, 2023. 1 changed file with 4 additions and 2 deletions.
    6 changes: 4 additions & 2 deletions Defensive-Programming.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,8 +1,10 @@
    Defensive programming.
    # Defensive programming

    There are complicated code pieces that all interlock with each other and it is easy for bugs to occur. Often these things are also difficult to test for since it is often chains of operations that need to happen and difficult to replicate
    There are complicated code pieces that all interlock with each other and it is easy for bugs to occur. Often these things are difficult to test for since it is often chains of operations that need to happen and difficult to replicate
    in a testing environment, but always seem to pop up in production.

    Functional tests can help but with complex system it is impossible to create test cases for all scenerios.

    One way I have found useful for this class of issues is called defensive programming.

    The basic idea is that at runtime parts of the code are aggressive that the data passed into it is correct. This is more than about typing. It is about validating from a logic perspective things are correct.
  4. Jbot29 created this gist Jun 13, 2023.
    40 changes: 40 additions & 0 deletions Defensive-Programming.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,40 @@
    Defensive programming.

    There are complicated code pieces that all interlock with each other and it is easy for bugs to occur. Often these things are also difficult to test for since it is often chains of operations that need to happen and difficult to replicate
    in a testing environment, but always seem to pop up in production.

    One way I have found useful for this class of issues is called defensive programming.

    The basic idea is that at runtime parts of the code are aggressive that the data passed into it is correct. This is more than about typing. It is about validating from a logic perspective things are correct.

    By identifying things and breaking there it is easier to find the chain that caused it. Often some code introduces a problem but only until it complete breaks things does an issue occur and it is hard to trace which part of the code
    intiated it.

    The problem with some systems is the change of events. Garbage flows downhill but it is is hard to tell which level introduced the breakage.
    With defensive programming the idea is that your code trusts nothing it gets and nopes out if it gets something it doesn't expect or like. With the hope that you short circuit difficult hard to trace bugs.

    https://python.plainenglish.io/defensive-programming-in-python-af0266e65dfd



    Benefits: Like a mix of live test cases, documents the expectations of the code

    Stopping errors from propagating down the stack.

    https://docs.pydantic.dev/latest/

    The best form of comments

    forces you to think and codify your assumptions


    Stack layer

    Each layer is just compounding earlier problems.



    Tests are great and we should have more, but the honest truth is they will never replicated the complexity of a real env with people doing crazy shit.


    Use typing, pydantic and asserts in critical areas of the code.