Repository navigation
feat(standoff)!: return XML alongside HTML for textValue with custom standoff mapping and default XSL transformation (DEV-201) - #1991
Conversation
BalduinLandolt
changed the title
irinaschubert
left a comment
irinaschubert
left a comment
There was a problem hiding this comment.
LGTM, just some comments/questions.
| case Some(v) => v | ||
| case None => FileModelUtil.getDefaultClassName(fileType) | ||
| } | ||
| val resorceIRIOrNothing = resourceIRI match { |
There was a problem hiding this comment.
Wouldn't maybeResourceIri better match our naming pattern or is there a reason why you used ...orNothing?
There was a problem hiding this comment.
I hate those maybeXY variable names. But if you feel it's important to be consistent with this, I can change it. And same goes for the acronyms: I much prefer IRI over Iri but I can change it, if you think the inconsistency hurts too badly.
There was a problem hiding this comment.
I prefer consistency for both cases. Because consistency let's us recognize similar constructs (which helps understanding code written by someone else) and also makes searching for certain constructs easier (although right now I don't know why I would want to search for all maybe... constructs - but you never know ;). This is just my opinion, maybe the others don't agree.
There was a problem hiding this comment.
@BalduinLandolt why is like that? maybe prefix is very descriptive and suggests what actually is stored in that named property.
We already agreed some time ago to use capital letters for acronyms in property names, so this would be maybeResourceIRI.
There was a problem hiding this comment.
I think the reason why I don't like "maybe" is because it's added at the beginning, so two variables don't look similar:
val something = "foo bar"
val maybeSomething = Some(something) // not clear on first glance that it's the same
val somethingOption = Some(something) // more clear on first glance that it's the sameDoes that make sense? But I'm absolutely OK with "maybe" if you think it's good.
However, in this case it's not actually correct to call it maybeResourceIRI because it's not an option, it's either a string or an empty string, depending on the input. I'll rename it to resourceIRIOrEmptyString
There was a problem hiding this comment.
Yeah that is the downside. From the other hand, if we use typing everywhere, we could skip naming properties like that, because type annotation strictly say what is this. somethingMaybe aka callMeMaybe ;) could be also another idea.
There was a problem hiding this comment.
I see your point. Still, it is the naming pattern we have right now and in my opinion it makes it easier to understand the code if the pattern is the same everywhere. We could still introduce a new naming pattern in V3. As the value here is not an option, you are actually right that it doesn't have to match the naming pattern of options. So, IMO you can as well call it resourceIRIOrEmptyString.
There was a problem hiding this comment.
please don't change patterns in a codebase that uses this pattern all over the place. Either it is changed everywhere or keep the to the current convention. conventions need to be carefully analysed and then when agreed upon used by everybody. you can add it to the list of changes that you would like to see in the new codebase.
|
Kudos, SonarCloud Quality Gate passed!
|
4 participants
resolves DEV-201