-
Notifications
You must be signed in to change notification settings - Fork 5
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
Resolve detekt findings #54
Conversation
jcenter() | ||
jcenter { | ||
content { | ||
includeGroup("org.jetbrains.kotlinx") |
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.
Required for HTML reports. We might also use kotlinx for introducing truly immutable lists in the data classes again, for safety in Java.
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.
Is that lib released? Immutable collections I mean.
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.
Hm, I've just read up on it here, without checking the release status. Seems it's still in pre-release.
public fun addAllAuthorBuilder(authorBuilders: List<PersonBuilder>): AtomBuilder = | ||
apply { authorBuilders.forEach(::addAuthorBuilder) } |
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.
These are in accordance with the formatting of expression-bodies (even though especially scope functions are nice on the same line as the =
)
@@ -1,3 +1,5 @@ | |||
@file:Suppress("TooManyFunctions") |
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.
I've suppressed the TooManyFunctions in builders since we need at least as many methods in them as there are properties in their data class models.
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.
I think we can simply suppress TooManyFunctions and TooManyParameters entirely, they don't really make too much sense when dealing with large models and files with top-level functions
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.
Do you have a favourite config file at hand that we can use? Might be quicker than setting one up from scratch.
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.
I'll try to find something
override fun applyFrom(prototype: EpisodeGoogleplay?): EpisodeGoogleplayBuilder = whenNotNull(prototype) { googleplay -> | ||
author(googleplay.author) | ||
description(googleplay.description) | ||
explicit(googleplay.explicit?.type) | ||
block(googleplay.block) | ||
imageBuilder(HrefOnlyImage.builder().applyFrom(googleplay.image)) | ||
override fun applyFrom(prototype: EpisodeGoogleplay?): EpisodeGoogleplayBuilder { | ||
return whenNotNull(prototype) { googleplay -> | ||
author(googleplay.author) | ||
description(googleplay.description) | ||
explicit(googleplay.explicit?.type) | ||
block(googleplay.block) | ||
imageBuilder(HrefOnlyImage.builder().applyFrom(googleplay.image)) | ||
} |
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.
Alternative here could be:
override fun applyFrom(prototype: EpisodeGoogleplay?): EpisodeGoogleplayBuilder =
whenNotNull(prototype) { googleplay ->
author(googleplay.author)
description(googleplay.description)
explicit(googleplay.explicit?.type)
block(googleplay.block)
imageBuilder(HrefOnlyImage.builder().applyFrom(googleplay.image))
}
but that's not really a single line expression body anymore.
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 not a single line but it it a single expression. Personal taste would prefer the expression body syntax, but easy either way
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.
I also prefer the single expression tbh. Just wanted to stick to the convention as closely as possible. But if you're also preferring it, I'll change it then.
override fun addAuthorBuilder(authorBuilder: PersonBuilder): AtomBuilder = apply { | ||
authorBuilders.add(authorBuilder) | ||
} | ||
override fun addAuthorBuilder(authorBuilder: PersonBuilder): AtomBuilder = | ||
apply { authorBuilders.add(authorBuilder) } |
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 consistency, I've refactored these as well to new line expression bodies, even though the lines have not been too long here. Preferred the previous style more though.
@Suppress("ReturnCount") | ||
internal fun Node.toItunesCategory(namespace: FeedNamespace? = null): ItunesCategory? { | ||
val categoryValue = getAttributeValueByName("text")?.trim() ?: return null | ||
val category = ItunesCategory.of(categoryValue) ?: return null |
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.
The alternatives I came up with were harder to read and still had too many returns 😅
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.
Suppression is ok here too yep
@Suppress("MagicNumber") | ||
private val dayOfWeek = mapOf( | ||
1L to "Mon", | ||
2L to "Tue", |
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.
Felt stupid to introduce constants here.
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.
Absolutely :)
@@ -1,3 +1,5 @@ | |||
@file:Suppress("TooManyFunctions") |
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.
Also suppressed TooManyFunctions in the extensions, since we have as many extensions as we like.
"contributor" -> ifCanBeParsed { toPersonBuilder(personBuilderProvider.createPersonBuilder(), namespace) } | ||
?.let(atomBuilder::addContributorBuilder) |
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.
Parsers suffered from both MaxLineLength and ReturnCount. Solved with ?.let
and by only passing the function pointer.
@@ -87,7 +83,10 @@ internal object PodcastindexParser : NamespaceParser() { | |||
.type(type) | |||
} | |||
|
|||
private fun Node.toSoundbiteBuilder(soundbiteBuilder: EpisodePodcastindexSoundbiteBuilder): EpisodePodcastindexSoundbiteBuilder? { | |||
@Suppress("ReturnCount") |
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.
Again, not better idea for this method.
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 ok, it was already the smallest/simplest implementation in my mind 👯
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.
I'd turn off those rules mentioned in the comments, so we can spare ourselves some suppressions. Looks good for the rest!
I've disabled the mentioned rules. Since the ReturnCount is obsolete now, I've also reverted the parsers to their previous state, for better readability. |
Ace, I'll try to get you a detekt config file asap, may need to patch it up from other projects I have :) |
Seb's detekt ruleset, and relevant fixes
I think we can ship now 💯 |
Bit of stuff is still in my pipeline. Found another issue with specs actually 😅 |
Huh, curious to see what. But can always be a separate PR :) |
This PR closes #52 by resolving the issues found by detekt. I did not add any custom rules so far, but we might want to do that in the future(?). We've had mostly MaxLineLength and ReturnCount issues.
Some resulting constructs are definitely worth debating, and I'm not super happy with quite a few of them. I did not
@Suppress
too much and only when refactoring would have been very inconvenient.