chore: fix linter warnings

[crodriguezvega]

Description

There were mainly 3 warning types:

• variables names cap redefined a built-in function.
• redundant if ...; err != nil check when it would be possible to just return the function called.
• Unused named parameters.

closes: #XXXX

Commit Message / Changelog Entry

N/A

see the guidelines for commit messages. (view raw markdown for examples)

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md).
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards and Go style guide.
• Wrote unit and integration tests.
• Updated relevant documentation (docs/) or specification (x/<module>/spec/).
• Added relevant godoc comments.
• Provide a commit message to be used for the changelog entry in the PR description for review.
• Re-reviewed Files changed in the Github PR explorer.
• Review Codecov Report in the comment section below once CI passes.

[crodriguezvega]

This linter rule complains when a named argument in a functions is not used

[chatton]

Thanks for sorting out these issues, maybe we can pin the linter to the current latest version in the workflow so we don't run into this issue unexpectedly again? WDYT?

[damiannolan]

Thanks @crodriguezvega ❤️

[damiannolan]

so an update to the linter started to trigger all these?
sometimes I prefer an explicit function call, and there may be scenarios where we may want to log something.

Happy to honour the linter here, just playing devils advocate. I think sometimes linters can be overly aggressive. We can always tweak the config later I guess.

[DimitrisJim]

It might be beneficial to add //nolint directives in that case with an additional comment for context or is that too noisy? I can definitely remember cases where a linter was being silly.

[crodriguezvega]

Yes, looks like golangci-lint was bumped to v1.52 and hell broke loose...

I had second thoughts when I was changing these as well, but thought the improvement was justified. I don't think the link would have complained if there was some extra logic inside the if statement.

[crodriguezvega]

It might be beneficial to add //nolint directives in that case with an additional comment for context or is that too noisy? I can definitely remember cases where a linter was being silly.

Yes, thank you for the suggestion, @DimitrisJim, we do use those directives in some places of the codebase.

[colin-axner]

I agree with @damiannolan, I think it'd be nice to be able to turn off this specific linting check. I don't see a lot of value in enforcing it, but I do see value in not enforcing it

[crodriguezvega]

maybe we can pin the linter to the current latest version in the workflow so we don't run into this issue unexpectedly again? WDYT?

I can do that, if you guys prefer that. To me fixing these warnings when they pop up is not a big deal, but if it's disturbing for the rest, I am fine fixing the version.

[chatton]

maybe we can pin the linter to the current latest version in the workflow so we don't run into this issue unexpectedly again? WDYT?

I can do that, if you guys prefer that. To me fixing these warnings when they pop up is not a big deal, but if it's disturbing for the rest, I am fine fixing the version.

My main concern is that periodically linting that works locally will cause failures on CI, I. would prefer to intentionally upgrade the linter periodically so CI stays consistent until we change it ourselves.

[crodriguezvega]

My main concern is that periodically linting that works locally will cause failures on CI, I. would prefer to intentionally upgrade the linter periodically so CI stays consistent until we change it ourselves.

All right, I fixed the version.

[chatton]

Thanks for fixing these issues 🥇