-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add a "cognitive trust" score and linters. #18
Comments
golangci-lint comes to mind as one of the most used tools to lint in the go ecosystem, with many plugins and a good integration in CI workflows. It could be a good starting point and an introduction to the already existing linters. |
Regarding the linting part, yes. I've started a PR for the linting aspect here: gnolang/gno#981. Regarding the other part, it's still uncertain whether it's worthwhile to create a scoring system for evaluating the "trust level" of code. We need more discussion and exploration to make a decision. |
I think it's useful to have something like "cognitive complexity" as a linter. But I think it would be very hard to create an automated filter for "bad code" with cognitive complexity. Do you have some ideas on how this could be implemented, maybe starting from something like gocognit which you mentioned to me? |
Let's explore the idea of measuring "cognitive trust" in projects, inspired by "cognitive complexity" linters. By identifying good and bad patterns among Gnolang contract developers, we can enhance our environment for building highly trustworthy apps and systems.
It's not just about scoring contracts; we want to make smart choices in VM features to minimize the risk of untrustworthy code. Our goal is to make it nearly impossible to create such code.
Considering our mission and unique advantage, let's document this approach. We could even measure cognitive trust in other languages and provide scores.
To improve contract quality, let's create our own set of linting rules. This will facilitate static analysis, promote unambiguous patterns, and reduce the cognitive load of working with multi-contract scenarios.
Your feedback and any existing work links are welcome. We might even consider sponsoring a PhD research project to delve deeper into this concept.
Related with #17 (comment)
The text was updated successfully, but these errors were encountered: