Refactor ConditionBasedFilter when-filter to use ternary operator - #5281
#5281Refactor ConditionBasedFilter when-filter to use ternary operator#5281snakefoot merged 2 commits intoNLog:devNLog/NLog:devfrom jokoyoski:FilterResultCheckRefactoringjokoyoski/NLog:FilterResultCheckRefactoringCopy head branch name to clipboard
Conversation
|
Thanks for opening this pull request! |
| } | ||
|
|
||
| return FilterDefaultAction; | ||
| bool isConditionTrue = Condition.Evaluate(logEvent) == ConditionExpression.BoxedTrue; |
There was a problem hiding this comment.
Can it become:
object val = Condition.Evaluate(logEvent);
return ConditionExpression.BoxedTrue.Equals(val) ? Action : FilterDefaultAction;I like that ConditionExpression.BoxedTrue.Equals(val) avoids an additional null-check, and also limits the equals-operation to only boolean-comparison. I also like not having too many expressions in a single statement.
|
Have now fixed the Azure DevOps-pipeline with #5282, so if you rebase to dev-branch then they should become green. |
|
Okay will do that and made the update you advice. Thanks |
|
@snakefoot please check |
|
Kudos, SonarCloud Quality Gate passed! |
|
Hooray your first pull request is merged! Thanks for the contribution! Looking for more? 👼 Please check the up-for-grabs issues - thanks! |
In the refactored code, we directly compare the result of Condition.Evaluate(logEvent) with ConditionExpression.BoxedTrue to determine if the condition is true. Instead of assigning the result to val, we directly use the comparison result to determine the path of execution. This simplifies the code by removing the need for the if statement and condenses it into a single return statement.