DiKTat is a strict coding standard for Kotlin, consisting of a collection of Kotlin code style rules implemented as Abstract Syntax Tree (AST) visitors built on top of KTlint. It serves the purpose of detecting and automatically fixing code smells in the Continuous Integration/Continuous Deployment (CI/CD) process. You can find the comprehensive list of supported rules and inspections here.
DiKTat has gained recognition and has been added to the lists of static analysis tools, kotlin-awesome, and kompar. We extend our gratitude to the community for this support!
Codestyle | Inspections | Examples | Demo | White Paper | Groups of Inspections |
While there are other tools like detekt
and ktlint
performing static analysis, you might wonder why DiKTat is necessary. Here are the key reasons:
More Inspections: DiKTat boasts over 100 inspections tightly coupled with its Codestyle.
Unique Inspections: DiKTat introduces unique inspections not found in other linters.
Highly Configurable: Every inspection is highly configurable, allowing customization and suppression. Check configuration options and suppression.
Strict Codestyle: DiKTat enforces a detailed Codestyle that can be adopted and applied in your project.
Download diKTat manually: here
OR use curl
:
curl -sSLO https://github.com/saveourtool/diktat/releases/download/v2.0.0/diktat && chmod a+x diktat
For Windows only. Download diKTat.cmd manually: here
Finally, run KTlint (with diKTat injected) to check your '*.kt' files in 'dir/your/dir':
$ ./diktat "dir/your/dir/**/*.kt"
On Windows
diktat.bat "dir/your/dir/**/*.kt"
To autofix all code style violations, use --mode fix
option.
You can see how it is configured in our examples:
<details> <summary>Add this plugin to your pom.xml:</summary></details><plugin> <groupId>com.saveourtool.diktat</groupId> <artifactId>diktat-maven-plugin</artifactId> <version>${diktat.version}</version> <executions> <execution> <id>diktat</id> <phase>none</phase> <goals> <goal>check</goal> <goal>fix</goal> </goals> <configuration> <inputs> <input>${project.basedir}/src/main/kotlin</input> <input>${project.basedir}/src/test/kotlin</input> </inputs> <diktatConfigFile>diktat-analysis.yml</diktatConfigFile> <excludes> <exclude>${project.basedir}/src/test/kotlin/excluded</exclude> </excludes> </configuration> </execution> </executions> </plugin>
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:
In your pom.xml
, you have multiple executions with different
configurations (e. g.: multiple rule sets):
</details><executions> <execution> <id>diktat-basic</id> <configuration> <diktatConfigFile>diktat-analysis.yml</diktatConfigFile> </configuration> </execution> <execution> <id>diktat-advanced</id> <configuration> <diktatConfigFile>diktat-analysis-advanced.yml</diktatConfigFile> </configuration> </execution> </executions>
Your YAML file with DiKTat rules has a non-default name and/or resides in a non-default location:
<details></details><executions> <execution> <id>diktat</id> <configuration> <diktatConfigFile>/non/default/rule-set-file.yml</diktatConfigFile> </configuration> </execution> </executions>
diktatConfigFile
or if it points to non-existed file
then DiKTat runs with default configuration.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 7.0
You can see how the plugin is configured in our examples:
<details> <summary>Add this plugin to your `build.gradle.kts`:</summary>plugins { id("com.saveourtool.diktat") version "2.0.0" }
Note If you want to apply the plugin to multi-module projects"
import com.saveourtool.diktat.plugin.gradle.DiktatGradlePlugin plugins { id("com.saveourtool.diktat") version "2.0.0" apply false } allprojects { apply<DiktatGradlePlugin>() }
You can then configure diktat using diktat
extension:
diktat { inputs { include("src/**/*.kt") // path matching this pattern (per PatternFilterable) that will be checked by diktat exclude("src/test/kotlin/excluded/**") // path matching this pattern will not be checked by diktat } debug = true // turn on debug logging }
Also in diktat
extension you can configure different reporters and their output. You can specify json
, html
, sarif
, plain
(default).
If output
is set, it should be a file path. If not set, results will be printed to stdout.
You can specify multiple reporters.
If no reporter is specified, plain
will be used with stdout
as output.
</details>diktat { reporters { plain() json() html { output = file("someFile.html") } // checkstyle() // sarif() // gitHubActions() } }
You can run diktat checks using task ./gradlew diktatCheck
and automatically fix errors with task ./gradlew diktatFix
.
Spotless is a linter aggregator.
Diktat can be run via spotless-gradle-plugin since version 5.10.0
<details> <summary>Add this plugin to your build.gradle.kts</summary></details> <details> <summary>You can provide a version and configuration path manually as configFile.</summary>plugins { id("com.diffplug.spotless") version "5.10.0" } spotless { kotlin { diktat() } kotlinGradle { diktat() } }
</details>spotless { kotlin { diktat("2.0.0").configFile("full/path/to/diktat-analysis.yml") } }
Diktat can be run via spotless-maven-plugin since version 2.8.0
<details> <summary>Add this plugin to your pom.xml</summary></details> <details> <summary>You can provide a version and configuration path manually as configFile</summary><plugin> <groupId>com.diffplug.spotless</groupId> <artifactId>spotless-maven-plugin</artifactId> <version>${spotless.version}</version> <configuration> <kotlin> <diktat /> </kotlin> </configuration> </plugin>
</details><diktat> <version>2.0.0</version> <!-- optional --> <configFile>full/path/to/diktat-analysis.yml</configFile> <!-- optional, configuration file path --> </diktat>
We suggest everyone to use common "sarif" format as a reporter
in CI/CD.
GitHub has an integration
with SARIF format and provides you a native reporting of diktat issues in Pull Requests.
Gradle Plugin:
githubActions = true
Maven Plugin (pom.xml):
<githubActions>true</githubActions>
Maven Plugin (cli options):
mvn -B diktat:check@diktat -Ddiktat.githubActions=true
- name: Upload SARIF to Github using the upload-sarif action uses: github/codeql-action/upload-sarif@v1 if: ${{ always() }} with: sarif_file: ${{ github.workspace }}
Note: codeql-action/upload-sarif
limits the number of uploaded files at 15. If your project has more than 15 subprojects,
the limit will be exceeded and the step will fail. To solve this issue one can merge SARIF reports.
diktat-gradle-plugin
provides this capability with mergeDiktatReports
task. This task aggregates reports of all diktat tasks
of all Gradle project, which produce SARIF reports, and outputs the merged report into root project's build directory. Then this single
file can be used as an input for GitHub action:
</details>with: sarif_file: build/reports/diktat/diktat-merged.sarif
diktat-analysis.yml
In Diktat 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.
For example:
</details> <details> <summary>Disable all inspections on selected code blocks</summary> Also you can suppress **all** warnings by adding `@Suppress("diktat")` annotation on individual code blocks.@Suppress("FUNCTION_NAME_INCORRECT_CASE") class SomeClass { fun methODTREE(): String { } }
For example:
</details> <details> <summary>ignoreAnnotated: disable inspections on blocks with predefined annotation</summary> In the `diktat-analysis.yml` file for each inspection it is possible to define a list of annotations that will cause disabling of the inspection on that particular code block:@Suppress("diktat") class SomeClass { fun methODTREE(): String { } }
</details> <details> <summary>Suppress groups of inspections by chapters</summary> It is easy to suppress even groups of inspections in diKTat.- name: HEADER_NOT_BEFORE_PACKAGE enabled: true ignoreAnnotated: [MyAnnotation, Compose, Controller]
These groups are linked to chapters of Codestyle.
To disable chapters, you will need to add the following configuration to common configuration (- name: DIKTAT_COMMON
):
disabledChapters: "1, 2, 3"
Mapping of inspections to chapters can be found in Groups of Inspections.
</details>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:
./diktat --baseline=diktat-baseline.xml
AI数字人视频创作平台
Keevx 一款开箱即用的AI数字人视频创作平台,广泛适用于电商广告、企业培训与社媒宣传,让全球企业与个人创作者无需拍摄剪辑,就能快速生成多语言、高质量的专业视频。
一站式AI创作平台
提供 AI 驱动的图片、视频生成及数字人等功能,助力创意创作
AI办公助手,复杂任务高效处理
AI办公助手,复杂任务高效处理。办公效率低?扣子空间AI助手支持播客生成、PPT制作、网页开发及报告写作,覆盖科研、商业、舆情等领域的专家Agent 7x24小时响应,生活工作无缝切换,提升50%效率!
AI辅助编程,代码自动修复
Trae是一种自适应的集成开发环境(IDE),通过自动化和多元协作改变开发流程。利用Trae,团队能够更快速、精确地编写和部署代码,从而提高编程效率和项目交付速度。Trae具备上下文感知和代码自动完成功能,是提升开发效率的理想工具。
AI小说写作助手,一站式润色、改写、扩写
蛙蛙写作—国内先进的AI写作平台,涵盖小说、学术、社交媒体等多场景。提供续写、改写、润色等功能,助力创作者高效优化写作流程。界面简洁,功能全面,适合各类写作者提升内容品质和工作效率。
全能AI智能助手,随时解答生活与工作的多样问题
问小白,由元石科技研发的AI智能助手,快速准确地解答各种生活和工作问题,包括但不限于搜索、规划和社交互动,帮助用户在日常生活中提高效率,轻松管理个人事务。
实时语音翻译/同声传译工具
Transly是一个多场景的AI大语言模型驱动的同声传译、专业翻译助手,它拥有超精准的音频识别翻译能力,几乎零延迟的使用体验和支持多国语言可以让你带它走遍全球,无论你是留学生、商务人士、韩剧美剧爱好者,还是出国游玩、多国会议、跨国追星等等,都可以满足你所有需要同传的场景需求,线上线下通用,扫除语言障碍,让全世界的语言交流不再有国界。
一键生成PPT和Word,让学习生活更轻松
讯飞智文是一个利用 AI 技术的项目,能够帮助用户生成 PPT 以及各类文档。无论是商业领域的市场分析报告、年度目标制定,还是学生群体的职业生涯规划、实习避坑指南,亦或是活动策划、旅游攻略等内容,它都能提供支持,帮助用户精准表达,轻松呈现各种信息。
深度推理能力全新升级,全面对标OpenAI o1
科大讯飞的星火大模型,支持语言理解、知识问答和文本创作等多功能,适用于多种文件和业务场景,提升办公和日常生活的效率。讯飞星火是一个提供丰富智能服务的平台,涵盖科技资讯、图像创作、写作辅助、编程解答、科研文献解读等功能,能为不同需求的用户提供便捷高效的帮助,助力用户轻松获取信息、解决问题,满足多样化使用场景。
一种基于大语言模型的高效单流解耦语音令牌文本到语音合成模型
Spark-TTS 是一个基于 PyTorch 的开源文本到语音合成项目,由多个知名机构联合参与。该项目提供了高效的 LLM(大语言模型)驱动的语音合成方案,支持语音克隆和语音创建功能,可通过命令行界面(CLI)和 Web UI 两种方式使用。用户可以根据需求调整语音的性别、音高、速度等参数,生成高质量的语音。该项目适用于多种场景,如有声读物制作、智能语音助手开发等。
最新AI工具、AI资讯
独家AI资源、AI项目落地
微信扫一扫关注公众号