Skip to content
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

Disable unhelpful linters #957

Closed
wants to merge 4 commits into from
Closed

Conversation

nirs
Copy link
Member

@nirs nirs commented Jul 4, 2023

Some linters used by golangci-lint are not helpful and enforce worse
code style. Disabling the linters allows improving the style and remove
unneeded obstacles for developers.

This pr modifies only 2 files to show some examples of possible formatting.
We can deffer the actual changes and modify the code as needed later.

nirs added 4 commits July 4, 2023 19:27
Return update result instead of keeping it in temporary error and remove
unneeded error definition.

Signed-off-by: Nir Soffer <[email protected]>
The current nlreturn golangci-lint rule is bad, leading to worse code
style like:

    if err != nil {
        log.Info("Something failed");

        return err;
    }

Disable the rule so we can format code properly.

Signed-off-by: Nir Soffer <[email protected]>
The rules of this linter forces bad style and I could not find how to
disable the rule for adding blank line before return.

An example of bad style required by wsl:

    if condition {
            log.Info("Long message so we move extra arguments to next line...",
                    "name", name,
                    "namespace", namespace)

            return true
    }

Signed-off-by: Nir Soffer <[email protected]>
In drcluster module and tests. This was not possible before because of
the golangci-lint nlreturn rule and wsl linter.

Same change is needed in rest of the code, starting with these modules
as example for possible changes.

Signed-off-by: Nir Soffer <[email protected]>
@ShyamsundarR
Copy link
Member

go linters can be very prescriptive, my current philosophy is to leave them be unless the cause a very severe irritation that it needs to be dropped (which we have not yet come across).

I would hence not drop these linters (or any linters) as it keeps the code formatted in certain very strict ways.

We actually lost a few linters due to this PR #534 and potentially need to bring them back in, and also in general address some linter upgrade/deprecation warnings as seen here. This may need addressing soon than dropping linters.

@ShyamsundarR
Copy link
Member

Closing as stale, part of general cleanup. Please reopen and update if still required. (Also, we need to rekindle the linters efforts opened on other PRs than deprecating them)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants