Sider Documentation

Sider Documentation

›Custom Rules

Getting Started

  • Home
  • Intro Videos
  • Setting up Sider
  • Dashboard Overview
  • Repository Settings
  • Custom Analysis Configuration
  • Working with Issues
  • Permissions
  • Skip Analyzing

Analysis Tools

    Ruby

    • RuboCop
    • Reek
    • Querly
    • Rails Best Practices
    • Brakeman
    • HAML-Lint

    Java

    • Checkstyle
    • PMD
    • JavaSee

    Kotlin

    • ktlint

    JavaScript and Flavors

    • ESLint
    • JSHint
    • TSLint
    • TyScan
    • CoffeeLint

    CSS

    • stylelint
    • SCSS-Lint

    PHP

    • Phinder
    • PHPMD
    • PHP_CodeSniffer

    Python

    • Flake8

    Swift

    • SwiftLint

    Go

    • go vet
    • Golint
    • Go Meta Linter

    C/C++

    • Cppcheck
    • cpplint

    Shell script

    • ShellCheck

    Others

    • Goodcheck
    • Misspell

Custom Rules

  • Intro to Custom Rules
  • Goodcheck
  • Tips & Tricks

Advanced Settings

  • Inline Comments
  • Private Dependencies
  • Restricting access to Close button
  • Transferring a repository

Billing and Plans

  • Billing and Plans

Troubleshooting

  • Troubleshooting

Enterprise

  • Outline
  • Quickstart
  • Computer Resources
  • GitHub Setup
  • Database Guide
  • Object Storage Guide
  • Containers Guide
  • Updating Guide
  • Administration Guide
  • Scaling Guide
  • Configuration Index
  • Health Check Guide
  • Releases

    • Summary
    • 201911
    • Older releases

News

  • 2019
Edit

Introduction to Custom Rules

What are Custom Rules?

Custom rules are sets of code patterns and messages used by Sider’s supported static code analyzers. You write custom rules to enforce your projects guidelines and share code-base knowledge. If the rules match a pattern in the code, they report a message.

Why it matters?

Sharing code-base knowledge has many benefits to help improve projects, but sharing this information can be tedious and impractical. Creating custom rules provides a practical solution to embed project knowledge into your workflow, alerting your team of issues when they need it.

What are the tools?

Sider currently supports 3 tools to analyze against custom rules.

  • Goodcheck for general text source code.
  • Querly for Ruby.
  • Phinder for PHP.

Goodcheck

Goodcheck is a tool that takes custom rules and matches the pattern with code. The rule’s patterns are defined with regular expressions which allow it to work across all or specific text source code.

In this example, we look at maintaining consistent wording. When a user sees both “Sign in” and “Log in” within your web application, it may cause confusion or detract from the user experience.

rules:
  - id: review.sider.wording.signin
    pattern:
      - token: Log in
        case_sensitive: false
      - token: Log out
        case_sensitive: false
    glob: 
      - "**/*.html.erb"
      - "**/*.yml"
    message: |
      Please use “sign in”/“sign out”.

      We use “sign in” instead of “log in” and “sign out” instead of “log out”.
      See the wording policy for details.

      https://docs.example.com/1840
    fail:
      - "Log in"
      - "Log out"
    pass:
      - "Sign in"
      - "Sign out"

In this example, Goodcheck will analyze files with .html, .erb and .yml extensions for the pattern “Log in” or “Log out”. If the pattern is found, it would display the message “Please use “sign in”/”sign out".”

Querly

Querly is a tool that understands Ruby syntax. It can take more complex patterns and find them in Ruby code.

In this example, assume there is an oauth_token method in your codebase. It is a credential and should not be leaked to logs. A developer adds a new option filtered. When filtered is true, the method returns an obfuscated token instead of a raw token so that you can write the obfuscated token on logs. Note that the behavior of oauth_token cannot be changed because the method is already used in the codebase.

rules:
  - id: sider.auth_token
    pattern: "_.oauth_token(!filtered: true)"
    message: |
      OAuth tokens are credential! Make sure they are filtered in logs.
    justification:
      - When you need an authentication for API calls
    examples:
      - before: "user.oauth_token[0...8] + '...'"
        after: "user.oauth_token(filtered: true)"

With this rule, Querly would analyze Ruby source code files for any Ruby expression that includes the oauth_token method and checks if there is filtered: true as an argument. If there isn’t, then a message will notify developers of the filtered option.

Phinder

Phinder is a tool that understands PHP syntax. It can take complex PHP patterns and match them with PHP code.

Assume your service had an outage because of a PostCategory::import_records(associations) call. The method implements bulk insertion of given rows into a table. It is faster than inserting the rows one by one but may result in a deadlock, which is what caused the service outage. You can put links to the issue reports to help the developer to understand what they have to do to make the function call safe.

- id: com.example.app.article 
  pattern: "_::import_records(_)" 
  message: | 
    `import_records(associations)` may block DB access 

    Read the following reports and double check the method call does not block DB access. 

    - https://github.com/example/server/issue/1234 
    - https://github.com/example/server/issue/1551

In this example, Phinder will match any PHP expression with a import_records class method. If there is a match, the message directs developers to the proper steps needed to make the function call safe.

Explainer Video

← MisspellGoodcheck →
  • What are Custom Rules?
  • Why it matters?
  • What are the tools?
    • Goodcheck
    • Querly
    • Phinder
  • Explainer Video
Sider Documentation
Docs
Getting StartedAnalysis ToolsEnterprise
Sider
Sider TopTerms of ServicePrivacy
Social
BlogGitHubStar
Copyright © 2019 Sider, Inc.