Adjust Severity Levels for Lint Rules

[notJoon]

Description

Currently, linter rules have a uniform severity level set to SeverityError. However, this approch doesn't accurately reflect the priorities of different linting issues. So, we need to adjust severity levels to better guide developers and prioritize fixes.

Objective

Refine out the severity levels of our lint rules to more accurately reflect their impact on code quality, readability, and potential for causing runtime issues.

Proposed Changes

1. Severity Level Definitions

I propose using the following severity levels:

• SeverityError: For issues that could lead to runtime errors, security vulnerabilities.
• SeverityWarning: For style-related issues that don't affect functionality but impact readability or maintainability.
• SeverityInfo: For suggestions and best practices that are good to know but not crucial. [NOT SURE]
• SeverityOff: For rules that are disabled by default but can be enables as needed.

2. Reclassification Guidelines

Based on previous paragraph, we need to reclassify our existing lint rules based on the following criteria:

SeverityError

• Potential runtime errors
• Incorrect use of language features
• Security vaulnerabilities
• Use of deprecated function/packages

SeverityWarning

• Code style inconsistencies (e.g., mixed identation)
• Potential performance issues
• Unused variables or imports (golangci-lint unused)
• Violations of Go/Gno conventions

SeverityInfo

• Suggestions for more idiomatic Go/Gno code.

SeverityOff

• Project-specific or highly opinionated rules

Please comment on this issue with your thoughts, concerns, or suggestions regarding this severity level adjustment plan.

---

Related with #82, #91

cc: @0xtekgrinder

[0xtekgrinder]

I agree with those suggested changes to the default severity.

However, note that in the current implementation setting to SeverityOff won't just remove all the issues, we will need to update the codebase to have this functionnality.