The way I think of invariants is in less formal terms, but which I find helpful on a day-to-day basis. Often, we write code that manipulates state. It can be di

The way I think of invariants is in less formal terms, but which I find helpful on a day-to-day basis. Often, we write code that manipulates state. It can be difficult to reason about code that manipulates state if we can't narrow down the possible states an object or struct can be in during execution. Invariants in our code or design can help narrow down this space of possible states by ensuring that certain combinations are impossible. For instance, assume I have an object that contains an array of integers and a boolean called `hasNegatives` which should be true if and only if the array contains at least one negative integer. If the boolean can be updated or set independent of the array, then the object can't really guarantee that the array and `hasNegatives` will always be "in sync" so to speak. If your code promises to maintain that invariant (by, for instance, making `hasNegatives` read only and privately updating it when the setter for the array is called to match what's inside the array) then when using this object or seeing an instance of it elsewhere in the code you can happily use it with confidence knowing that the field is always correct with respect to the array within. Obviously, this is a simplified example, but when applied to an object with many fields, knowing that only certain valid combinations are possible can radically simplify the rest of your code that interacts with that object.