Strict coding standard for Kotlin and a custom set of rules for detecting code smells, code style issues and bugs
DiKTat is a strict coding standard for Kotlin and a collection of Kotlin code style rules implemented as AST visitors on the top of KTlint. It can be used for detecting and autofixing code smells in CI/CD process. The full list of available supported rules and inspections can be found here.
Now diKTat was already added to the lists of static analysis tools, to kotlin-awesome and to kompar. Thanks to the community for this support!
Codestyle | Inspections | Examples | Demo | White Paper | Groups of Inspections |
There are several tools like detekt
and ktlint
that are doing static analysis. Why do I need diktat?
First of all - actually you can combine diktat with any other static analyzers. And diKTat is even using ktlint framework for parsing the code into the AST. Main features of diktat are the following:
1) More inspections. It has 100+ inspections that are tightly coupled with it’s Codestyle.
2) Unique Inspections that are missing in other linters.
3) Highly configurable. Each and every inspection can be configured or suppressed.
4) Strict detailed Codestyle that you can adopt and use in your project.
Install KTlint manually: here
OR use curl
:
# another option is "brew install ktlint"
curl -sSLO https://github.com/pinterest/ktlint/releases/download/0.46.1/ktlint && chmod a+x ktlint
Load diKTat manually: here
OR use curl
:
$ curl -sSLO https://github.com/saveourtool/diKTat/releases/download/v1.2.5/diktat-1.2.5.jar && chmod a+x diktat-1.2.5.jar
Finally, run KTlint (with diKTat injected) to check your ‘*.kt’ files in ‘dir/your/dir’:
$ ./ktlint -R diktat.jar --disabled_rules=standard,experimental,test,custom "dir/your/dir/**/*.kt"
To autofix all code style violations, use -F
option.
:heavy_exclamation_mark: If you are using Java 16+, you need to add --add-opens java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED
flag to the JVM. For more information, see: https://github.com/pinterest/ktlint/issues/1195
This can be done by setting MAVEN_OPTS
variable:
export MAVEN_OPTS="--add-opens java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED"
This plugin is available since version 0.1.3. You can see how it is configured in our project for self-checks: pom.xml. If you use it and encounter any problems, feel free to open issues on github.
To run diktat in only-check mode use command $ mvn diktat:check@diktat
.
To run diktat in autocorrect mode use command $ mvn diktat:fix@diktat
.
Requesting a specific Maven executionId
on the command line (the trailing
diktat
in the above example) may be essential in these cases:
pom.xml
, you have multiple executions with different
configurations (e. g.: multiple rule sets):
If you omit the executionId
:
$ mvn diktat:check
— the plug-in will use the default configuration and search for
diktat-analysis.yml
file in the project directory (you can still customize the
rule sets by editing the YAML file).
Requires a gradle version no lower than 5.3.
This plugin is available since version 0.1.5. You can see how the plugin is configured in our examples: build.gradle.kts.
You can run diktat checks using task diktatCheck
and automatically fix errors with tasks diktatFix
.
Spotless is a linter aggregator.
Diktat can be run via spotless-gradle-plugin since version 5.10.0
Diktat can be run via spotless-maven-plugin since version 2.8.0
We suggest everyone to use common “sarif” format as a reporter
(reporterType
) in CI/CD.
GitHub has an integration
with SARIF format and provides you a native reporting of diktat issues in Pull Requests.
diktat-analysis.yml
In KTlint, rules can be configured via .editorconfig
, but
this does not give a chance to customize or enable/disable
each and every rule independently.
That is why we have supported diktat-analysis.yml
that can be easily
changed and help in customization of your own rule set.
It has simple fields:
name
— name of the rule,
enabled
(true/false) — to enable or disable that rule (all rules are enabled by the default),
configuration
— a simple map of some extra unique configurations for this particular rule.
For example:
- name: HEADER_MISSING_OR_WRONG_COPYRIGHT
# all rules are enabled by the default. To disable add 'enabled: false' to the config.
enabled: true
configuration:
isCopyrightMandatory: true
copyrightText: Copyright (c) Jeff Lebowski, 2012-2020. All rights reserved.
Note, that you can specify and put diktat-analysis.yml
that contains configuration of diktat in the parent directory of your project on the same level where build.gradle/pom.xml
is stored.
See default configuration in diktat-analysis.yml
Also see the list of all rules supported by diKTat.
When setting up code style analysis on a large existing project, one often doesn’t have an ability to fix all findings at once. To allow gradual adoption, diktat and ktlint support baseline mode. When running ktlint for the first time with active baseline, the baseline file will be generated. It is a xml file with a complete list of findings by the tool. On later invocations, only the findings that are not in the baseline file will be reported. Baseline can be activated with CLI flag:
java -jar ktlint -R diktat.jar --baseline=diktat-baseline.xml **/*.kt
or with corresponding configuration options in maven or gradle plugins. Baseline report is intended to be added into the VCS, but it can be removed and re-generated later, if needed.
See our Contributing Policy and Code of Conduct