Development guidelines

[montyly]

Hi,

We are planning to create better development guidelines for Slither so we are looking for feedback from the community to know what components/design/process would help you.

We invite the community to answer in this thread with your documentation wishlist

[devtooligan]

some ideas:

• wiki guide to the apis for various classes which are useful when developing Slither
• walkthroughs of existing detectors that demo core Slither functionality
• a guide to writing a new detector in the form of a written step-by-step guide
• a guide to writing a new printer in the form of a written step-by-step guide

as for format, I think there is value in both written and video formats. curious to hear others opinions on that

[CJ42]

I think one good feature for the slither.config.json could be mention specific lines in the code where we want to disable some detectors. Similar to the option "detectors_to_exclude", but with the fine grained control to mention which lines in the contract code to exclude for a specific rule.

I know there is the triage mode available, but this is not always preferable if the contract is going to be deployed on mainnet. The Solidity code on Etherscan would show the comments //slither-disable low-level-call and it is not always wanted by the developer to show such comments in a live production contract.

[plotchy]

Love the initiative

With every detector needing to start from traversing the contracts/functions/nodes/irs themselves, I think more detail on how to traverse this and prune or filter by what is desired would be nice.
ie: how to prune out imported library fns that aren't going to be deployed in your contract, or prune out uninherited abstract contracts from a detector that cares about on-chain behavior (e.g: initialization of vars).

Possibly there could be an example catalog that documents this style of building blocks that aid in filtering.

For a crazy idea that may be out of scope of slither, I think an interactive playground for Solidity -> Slither IR (resembling the treesitter one) would greatly help in building the required learning of Slither IR and how a contract is parsed into it.

[tormentr]

needs rewrite in rust

[nick199910]

Implement an amusement park with a slither writing detector

[eMarchenko]

I'd like to have a default set of semi-realistic contracts to test new detectors. Every detector should behave decently at least on this benchmark, e.g.:

• Should produce limited number of alerts, so it doesn't dominate Slither's output
• Should detect as few problems as possible on high-quality code like OZ library
• New detectors could come with a realistic example, so they detect at least something in the benchmark. These examples should be from block explorers or third party repos.

[devtooligan]

a default set of semi-realistic contracts to test new detectors

I like this one. When I'm working on Slither I often end up creating my own sample contracts temporarily, and they are usually pretty light. Then, later I realize I made a mistake that would've been caught if I had used a more robust sample contract.