-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
minor: Fix sonarcube warnings #736
Conversation
JaCoCo code coverage report
|
if (attrIfd == id) true | ||
else dependsOnRec(attrMap(attrIfd).childRefs, id) | ||
attrIfd == id || dependsOnRec(attrMap(attrIfd).childRefs, id) | ||
case ExprRef(exprId) => | ||
if (exprId == id) true | ||
else { | ||
if (litMap.contains("exprId")) false | ||
else dependsOnRec(funMap(exprId).childRefs, id) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's shorter, but for me, the new version is harder to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about introducing an intermediate val? For example?
lazy val attrChildIds = attrMap(attrId).childRefs
lazy val anyChildRefsDepends = dependsOnRec(attrChildRefs, id)
attrIfd == id || anyChildRefsDepends
The main motivation was to comply with the Sonar rule.
Subjectively, I understand why this is usually recommended approach. First, it's shorter, but also it is more plural for the reader. There is less nesting and branching involved for the reader. You have entire resulted condition written in one sentence that IMO looks more natural, e.g. condition = this or that and not something_else
. But I agree that a lot depends on naming. So I wouldn't hesitate choosing better names for functions, or introducing intermediate variables.
On a side note, I just noticed that attrIfd
is probably a typo. Shouldn't it be attrId
? Also dependsOnRef
instead of dependsOnRec
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For simple cases, It may be ok, but here the second condition is more complex. The nesting and branching is still there, it just now must happen inside the reader's head instead of in the code. The reader must consider short-circuiting, negate one expression and operator precedence, and then build a truth table to make sense of it. The Sonar just doesn't consider any of that.
Shorter is not better, I think we should aim to minimize cognitive load.
Why do you mean by plural
?
attrIfd
yes typo
dependsOnRec
no it means recursive - just private name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
plural -> fluent. Crazy typo :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me refactor it a bit and I'll propose another variant.
Kudos, SonarCloud Quality Gate passed!
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but dependsOn
is good candidate to unit test
Fix SonarCloud warnings