You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Such checks (like 'Contains(tx)' here) can be removed/avoided. Let's explore three different scenarios:
When, the method Remove(tx) makes the same check internally. Therefore, we can remove the 'Contains(tx)' check outside the Remove method because it is redundant and unnecessary.
When the 'Remove' method does not perform these checks internally, and they are mandatory. In this case, it might be better to move this check inside the Remove method to avoid duplication and to adhere to principles such as co-locating data and behaviour or the Tell, don't ask principle.
When the 'Remove' method does not perform these checks, and they are not mandatory, their inclusion depends on the caller of the method. In this case, such checks can be removed with better error handling. For example, the method can return a custom error with fields containing information about the error. Based on this data, the caller can execute different business logic.
Using a custom error type can improves maintainability and also tends to be faster because usually it require less computational logic. Also, provide additional context and flexibility for error handling and decision-making in the application.
Note: This is not only for the method Remove. These approaches can be applied to any methods similar to it.
The text was updated successfully, but these errors were encountered:
In several places, I see code where we call a method from a type to perform a check and then call another method of the same type. For example:
or
Such checks (like 'Contains(tx)' here) can be removed/avoided. Let's explore three different scenarios:
When, the method Remove(tx) makes the same check internally. Therefore, we can remove the 'Contains(tx)' check outside the Remove method because it is redundant and unnecessary.
When the 'Remove' method does not perform these checks internally, and they are mandatory. In this case, it might be better to move this check inside the Remove method to avoid duplication and to adhere to principles such as co-locating data and behaviour or the Tell, don't ask principle.
When the 'Remove' method does not perform these checks, and they are not mandatory, their inclusion depends on the caller of the method. In this case, such checks can be removed with better error handling. For example, the method can return a custom error with fields containing information about the error. Based on this data, the caller can execute different business logic.
Using a custom error type can improves maintainability and also tends to be faster because usually it require less computational logic. Also, provide additional context and flexibility for error handling and decision-making in the application.
Note: This is not only for the method Remove. These approaches can be applied to any methods similar to it.
The text was updated successfully, but these errors were encountered: