Advice & answers from the codebeat team

New to codebeat? Want to learn more about our tool or how it can help you developer better code? You're in the right place! Go ahead and browse our documentation; you should find all the answers there.

You can also reach us directly through the live chat icon placed in the bottom right-hand corner.

Metrics customization

Your tweaks for codebeat rules

This is an advanced topic

Please consider exploring codebeat first and learning its' ins and outs before starting to tweak the default settings. Just because this feature is there does not mean you really need to use it 🐶

Although we put a lot of effort into calibrating our metrics you may occasionally find codebeat to be too strict or too lenient. Good news is that you can easily customize your codebeat experience by putting a .codebeatsettings file in the root of your project. It is a JSON configuration file which allows your to override any or all of the checks on a per-language basis. Please see an example file below:

  "SWIFT": {
    "TOO_MANY_IVARS": [8, 10, 14, 20]

This settings file will change the default number of allowed arguments for Swift. Note that there are four numbers here, each representing the threshold for a particular issue severity. In this case having fewer than 8 instance variables in a Swift class will raise no issue, having 8-9 will raise an issue with INFO severity, 10-13 will trigger WARNING, 14-19 - ERROR and 20 or more will lead to the highest possible severity - CRITICAL.

Note that for each override you must provide all four numbers, each for one severity level. These numbers must be monotonically increasing. If the configuration file is formatted incorrectly codebeat will fall back to default values.

Don't be too strict

At codebeat we tend to err on the side of caution and prefer to over- than underreport. When tweaking your codebeat settings you should probably think twice before introducing checks more strict that what we offer by default. Being too strict can lead to a great number of false positives which can eventually lead people to ignore codebeat and thus forego code quality. Before introducing your tweaks please make sure to read about each of the customizable metrics linked below, their default settings and the reasoning behind these.

Language keys

codebeat assumes that configuration is always provided on per-language basis. If your project uses multiple languages supported by codebeat you have a chance to explicitly specify overrides for each language you care about. In order to do that you will need to key your overrides by language symbol - "RUBY" for Ruby, "GOLANG" for Go, "SWIFT" for Swift, "OBJC" for Objective-C, "JAVA" for Java and "PYTHON" for Python.

Metrics keys

Within the language settings you can customise one ore more of the metrics. Below you will find the keys to use with an explanation of the metric itself.

"ABC" - Assignment Branch Condition size;
"ARITY" - number of function/method arguments;
"BLOCK_NESTING" - maximum block nesting;
"CYCLO" - cyclomatic complexity;
"LOC" - length (in terms of lines of code) of a function/method;
"RETURN_ARITY" - Number of return values (Go only);
"TOTAL_COMPLEXITY" - Total namespace complexity;
"TOTAL_LOC" - Namespace length in terms of lines of code;
"TOO_MANY_FUNCTIONS" - Number of functions in a given namespace;
"TOO_MANY_IVARS" - Number of instance variables in a given namespace;

Switching it off

While it's probably not a very good idea you can use metrics customization to turn off a particular check by setting some ridiculously high thresholds. Just keep in mind that metrics are often linked to each other, so for example if you don't care about how long your methods are (the "LOC" key) you should probably also consider ignoring the length of namespaces (the "TOTAL_LOC"), too.

Metrics customization

Your tweaks for codebeat rules