Skip to content

Latest commit

 

History

History
125 lines (101 loc) · 4.58 KB

CONTRIBUTING.md

File metadata and controls

125 lines (101 loc) · 4.58 KB
Raw

Issue report guidelines

Please insert every possible information you can obtain that could help us reproduce and triage your issue. This usually includes:

  • The relevant parts from CodeChecker's output.
  • The version number of CodeChecker – execute CodeChecker version --verbose debug and copy the value for Git tag info.
  • What you were trying to do.
  • What behaviour was expected instead of what happened.

Contribution guidelines

Python style

In CodeChecker, we use pycodestyle to automatically check our coding style. pycodestyle is enforced by the test infrastructure – if you write a new module outside the current directory structure, make sure to add its path to tests/Makefile under the pycodestyle target.

In addition to the general rules of pycodestyle, please keep the following rules while writing your code:

  • Comments must be whole sentences, beginning with a capital letter and ending with a closing ..

Order of import commands

Order your import commands according to as follows:

  1. System-wide imports come first and foremost, e.g. import multiprocessing.
  2. (Empty line for readability)
  3. External module/library imports that are not system-wide but related to CodeChecker's dependencies, e.g. from thrift import Thrift.
  4. (Empty line)
  5. API imports, e.g. import shared and from Authentication import ttypes. The only special rule about this clause is that import shared comes before every other API import.
  6. (Empty line)
  7. Modules from CodeChecker's own library's, libcodechecker.
  8. (Empty line)
  9. Imports from the package where the file you are writing is located in.

Between each of these levels, imports are sorted alphabetically on the importing module's name, even if we only import a single class or function from it.

Example

The example below should concisely show how module imports should be structured:

# ...General LICENSE information and file header...
"""
Documentation about the module.
"""

# -- 1. System specific imports
import atexit
from multiprocessing import Pool
import os
import tempfile

# -- 3. CodeChecker dependency imports
from alembic import config  # sorted as 'a'
import sqlalchemy
from sqlalchemy.engine import Engine
from thrift import Thrift
from thrift.Thrift import TException
from thrift.protocol import TJSONProtocol

# -- 5. API imports
import shared
from Authentication import codeCheckerAuthentication
from Authentication import constants
from codeCheckerDBAccess import codeCheckerDBAccess
from codeCheckerDBAccess.ttypes import *

# -- 7. libcodechecker and subpackages, etc.
from libcodechecker import host_check
from libcodechecker import util
from libcodechecker.analyze import analyzer
from libcodechecker.analyze.analyzers import analyzer_types
from libcodechecker.log import build_action
from libcodechecker.logger import LoggerFactory

# -- 9. imports from the local package
from . import client_db_access_handler
from product_db_access_handler import ThriftProductHandler

# ... your code here

Directory layout

libcodechecker is the folder where all CodeChecker related source code is found. CodeChecker is organised into different entry-points based on different features of the program, such as logging, analysing, result storage, web server, etc. All these features have their own module under libcodechecker.

A CodeChecker feature having its entry point consists of a bare minimum of two (2) things:

  • An entry point under bin/codechecker-myfeature.
  • The entry point's definition containing the feature's command-line help and argument parser under libcodechecker/myfeature.py.

Additionally, you may use different Python files to store code for your library for better code organisation. Library code related to myfeature go into the libcodechecker/myfeature folder.

If the library code is used between multiple subcommands, the file is put into libcodechecker itself. Please try to localise your library code in its own folder as much as possible.

Do NOT do cross-subcommand import, aka. from libcodechecker.analyze in a libcodechecker.myfeature file. This might change in the future as we consider how to make CodeChecker a more modular application.

Please execute scripts/create_new_subcommand.py myfeature to automatically generate the skeleton for myfeature. Already existing files, such as libcodechecker/log.py give a nice overview on how entry-point handlers should be laid out.