DEV Community: Marko Pavičić

Developing a Custom Gradle Plugin for Formatting and Static Analysis

Marko Pavičić — Wed, 31 Jul 2024 07:05:43 +0000

In our previous blogs, we explored how to integrate code formatting with ktfmt and static analysis with detekt into your projects. While these tools significantly improved our code quality and consistency, setting them up for each new project required much repetitive work. To streamline this process, we decided to develop a custom Gradle plugin that integrates both ktfmt and detekt, along with a pre-commit hook, ensuring consistent application across all our projects.

This blog will guide you through creating and publishing a custom Gradle plugin that automates the integration of ktfmt and detekt, simplifying the setup process for new projects.

We will cover publishing to a private Maven repository. If you want to publicly publish your plugin, refer to the Gradle documentation.

Note: We will cover publishing to a private Maven repository, therefore, this blog assumes you have a private Maven Repository Manager set up, such as Nexus, Artifactory, or similar. If you want to publish your plugin publicly to the Gradle Plugin Portal there are some small differences to this guide that you can check in this guide by the Gradle team.

This blog won't cover the specifics regarding ktfmt and detekt since that was covered in the previous blogs:

Integrating Code Formatting into Your Android Projects: dev.to, Medium

Enhancing Code Quality with detekt for Static Analysis: dev.to, Medium

Let's start with a short introduction to Gradle plugins.

Introduction to Gradle Plugins

Gradle plugins allow you to encapsulate reusable build logic, making it easy to apply standardized configurations across multiple projects. By developing a custom plugin, we can ensure that all our projects adhere to the same formatting and static analysis rules, reducing setup time and eliminating inconsistencies.

For more information refer to the Gradle documentation.

Let's dive into the steps to create our Gradle plugin.

Setting Up the Plugin Project

First, we need to create a new Gradle project our plugin. This project will define the logic for integrating ktfmt and detekt and applying the pre-commit hook.

Create a new directory for your plugin project:
```
  mkdir precommit
  cd precommit
```
Initialize a new Gradle project:
```
  gradle init
```
Select the options to create a new Gradle plugin project, we will use Kotlin and Kotlin DSL in this guide.

Configure the build.gradle.kts file: Open the build.gradle.kts file and add the following code in the plugins block:

  ...
  plugins {
      ...
      `kotlin-dsl`
      `maven-publish`
  }
  ...

In the code snippet above we apply the Kotlin DSL plugin and the Maven publish plugin which will be used upon publishing the plugin to a Maven repository.

Next, add the plugin project group and version:

  ...
  group = "org.example"
  version = "0.0.1" // You will use this version code when applying the plugin in other projects
  ...

After that, implement the ktfmt and detekt Gradle plugins:

  ...
  dependencies {
      implementation("com.ncorti.ktfmt.gradle:0.19.0") // Replace with the latest version
      implementation("io.gitlab.arturbosch.detekt:detekt-gradle-plugin:1.23.6") // Replace with the latest version
  }
  ...

Lastly, you should configure your plugin's definition in the gradlePlugin block:

  ...
  // Define the gradlePlugin block which contains the plugin configuration
  gradlePlugin {
   // Define the plugins block which contains the individual plugin definitions
      plugins {
          // Create a new plugin configuration with the name "precommit"
          create("precommit") {
              // Set the unique identifier for the plugin
              id = "org.example.precommit"
              // Set the display name for the plugin
              displayName = "precommit"
              // Provide the plugin description
              description =
               "Gradle plugin that adds a pre-commit hook to your project that runs detekt and ktfmt"
              // Assign tags to the plugin for easier discovery and categorization
              tags.set(listOf("pre-commit", "kotlin", "detekt", "ktfmt"))
              // Specify the fully qualified name of the class implementing the plugin
              implementationClass = "org.example.PreCommitPlugin"
          }
      }
  }

We want for the plugin to be configurable so it can be used across all Kotlin projects. We will allow the configurability by implementing a configuration interface.

Creating the Configuration Interface

The plugin should be able to work across a wide variety of Kotlin projects, enable users to use the ktfmt style they prefer and allow the users to use Jetpack Compose specific detekt configuration when necessary. To do that we have to define a configuration interface:

Create the Configuration interface: Inside the src/main/kotlin/org/example directory, create a new Kotlin file named PreCommitConfig.kt:

...
interface PreCommitConfig {
    val composeEnabled: Property<Boolean>
    val ktfmtStyle: Property<KtfmtStyle>
    val injectHookTaskPath: Property<String>
}

enum class KtfmtStyle {
    GOOGLE_STYLE,
    KOTLIN_STYLE
}

We define the following configuration fields:

Parameter	Type	Description
composeEnabled	Boolean	Indicates whether Compose-specific configuration is enabled. If set to true, detekt will include additional checks specific to Jetpack Compose projects
ktfmtStyle	KtfmtStyle	Specifies the ktfmt style to use for code formatting.
injectHookTaskPath	String	Defines the path to the Gradle task before which the pre-commit hook script will be installed, app:clean by default

After defining configurability let's implement the plugin logic.

Implementing the Plugin Logic

Next, we will create the plugin class and define the logic to apply ktfmt, detekt, and the pre-commit hook.

1. Creating the Plugin Class

First, we define the PreCommitPlugin class and create the PreCommitConfig extension:

class PreCommitPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        // Create an extension for plugin configuration
        val ext = project.extensions.create<PreCommitConfig>("preCommitConfig")

        // Load the pre-commit script resource
        val preCommitScriptResource =
            javaClass.classLoader.getResourceAsStream("scripts/pre-commit")
        val detektConfigResource = javaClass.classLoader.getResourceAsStream("detekt-config.yml")
        ...

Here, we set up the class and create an extension to hold configuration values. We also load resources for the pre-commit script and the detekt configuration.

2. Applying Plugins and Configurations

Next, we apply the ktfmt and detekt plugins and configure them based on the provided extension values:

        ...
        project.afterEvaluate {
            // Read configuration values, providing defaults if not set
            val composeEnabled = ext.composeEnabled.orNull ?: false
            val ktfmtStyle = ext.ktfmtStyle.orNull ?: KtfmtStyle.KOTLIN_STYLE
            val injectHookTask = ext.injectHookTaskPath.orNull ?: "app:clean"

            // Configure all subprojects
            allprojects {
                // Apply ktfmt plugin and configure based on the chosen style
                apply(plugin = "com.ncorti.ktfmt.gradle")
                extensions.configure<KtfmtExtension> {
                    when (ktfmtStyle) {
                        KtfmtStyle.GOOGLE_STYLE -> googleStyle()
                        KtfmtStyle.KOTLIN_STYLE -> kotlinLangStyle()
                    }
                }

                // Apply detekt plugin and configure
                apply(plugin = "io.gitlab.arturbosch.detekt")
                extensions.configure<DetektExtension> {
                    if (composeEnabled) {
                        // Use a specific config file for Compose projects
                        config.setFrom(file("$projectDir/config/detekt-config.yml"))
                        buildUponDefaultConfig = true
                    }
                    allRules = false // Don't enable all rules
                    autoCorrect = true // Enable auto-correction
                    parallel = true // Run detekt in parallel
                }

                // Add Compose detekt rules if Compose is enabled
                if (composeEnabled) {
                    dependencies { add("detektPlugins", "io.nlopez.compose.rules:detekt:0.4.5") } // Replace with latest version
                }
            }
                    ...

Here, we apply the necessary plugins and configure them according to the extension settings, including applying specific styles for ktfmt and setting up detekt with optional support for Compose projects.

3. Configuring detekt Reports

We ensure that the detekt tasks generate the desired report formats:

                        ...
                  // Configure detekt tasks for reporting
            tasks.withType<Detekt>().configureEach {
                reports {
                    // Enable the generation of an HTML report
                    html.required.set(true)

                    // Enable the generation of a TXT report
                    txt.required.set(true)

                    // Enable the generation of a Markdown (MD) report
                    md.required.set(true)
                }
            }
            ...

This code sets up detekt to generate HTML, text, and markdown reports.

4. Copying Configuration Files

Next, we define a task to copy the configuration file for detekt from the plugin resources to the project directory:

            ...
            // Task to copy the detekt config
            tasks.register<Copy>("copyDetektConfig") {
                description =
                    "Copies the detekt config from the plugin's directory to the app/config folder."
                group = "detektConfig"

                if (detektConfigResource != null) {
                    // Use a temporary file to handle the resource stream
                    val tempDir = Files.createTempDirectory("detekt-config-temp").toFile()
                    val tempFile = File(tempDir, "detekt-config.yml")
                    try {
                        Files.copy(
                            detektConfigResource,
                            tempFile.toPath(),
                            StandardCopyOption.REPLACE_EXISTING)
                        from(tempFile)
                        logger.log(
                            LogLevel.DEBUG, "Copying detekt config from: ${tempFile.absolutePath}")
                    } catch (e: Exception) {
                        logger.log(
                            LogLevel.ERROR, "Failed to copy detekt config resource: ${e.message}")
                    } finally {
                        detektConfigResource.close() // Close the resource stream
                    }
                } else {
                    logger.log(LogLevel.ERROR, "detekt config resource not found in the plugin.")
                }

                into("${rootDir}/app/config/")
                logger.log(LogLevel.DEBUG, "Copying detekt config to: ${rootDir}/app/config/")
            }
            ...

The following code defines a task that copies the git hook from the plugin's resources to the project's git hooks directory:

            ...
            // Task to copy the pre-commit hook script
            tasks.register<Copy>("copyGitHooks") {
                description = "Copies the git hooks from the plugin's directory to the .git folder."
                group = "gitHooks"

                if (preCommitScriptResource != null) {
                    // Use a temporary file to handle the resource stream
                    val tempDir = Files.createTempDirectory("git-hooks-temp").toFile()
                    val tempFile = File(tempDir, "pre-commit")
                    try {
                        Files.copy(
                            preCommitScriptResource,
                            tempFile.toPath(),
                            StandardCopyOption.REPLACE_EXISTING)
                        from(tempFile)
                        logger.log(
                            LogLevel.DEBUG, "Copying git hooks from: ${tempFile.absolutePath}")
                    } catch (e: Exception) {
                        logger.log(
                            LogLevel.ERROR, "Failed to copy git hooks resource: ${e.message}")
                    } finally {
                        preCommitScriptResource.close() // Close the resource stream
                    }
                } else {
                    logger.log(LogLevel.ERROR, "Git hooks resource not found in the plugin.")
                }

                into("${rootDir}/.git/hooks/")
                logger.log(LogLevel.DEBUG, "Copying git hooks to: ${rootDir}/.git/hooks/")
                if (composeEnabled) {
                    dependsOn("copyDetektConfig")
                }
            }
            ...

5. Installing Git Hooks

Finally, we create a task to make the git hooks executable and inject this task as a dependency of another specified task:

            ...
            // Task to install (make executable) the pre-commit hook
            tasks.register<Exec>("installGitHooks") {
                description = "Installs the pre-commit git hooks."
                group = "gitHooks"
                workingDir = rootDir
                commandLine = listOf("chmod")
                args("-R", "+x", ".git/hooks/")
                dependsOn("copyGitHooks")
                doLast { logger.info("Git hook installed successfully.") }
            }

            // Make the specified build task depend on installing the git hooks
            afterEvaluate { tasks.getByPath(injectHookTask).dependsOn(":installGitHooks") }
        }
    }
}

This task ensures the pre-commit hook script is executable and sets it up to run as a dependency of another specified task (e.g., app:clean).

The specified task depends on the installGitHooks task, installGitHooks depends on copyGitHooks and copyGitHooks depends on copyDetektConfig, in that way, we ensure all tasks are run as a dependency on the specified task.

Your PreCommitPlugin.kt should now look like this:

class PreCommitPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        // Create an extension for plugin configuration
        val ext = project.extensions.create<PreCommitConfig>("preCommitConfig")

        // Load the pre-commit script resource
        val preCommitScriptResource =
            javaClass.classLoader.getResourceAsStream("scripts/pre-commit")
        val detektConfigResource = javaClass.classLoader.getResourceAsStream("detekt-config.yml")

        project.afterEvaluate {
            // Read configuration values, providing defaults if not set
            val composeEnabled = ext.composeEnabled.orNull ?: false
            val ktfmtStyle = ext.ktfmtStyle.orNull ?: KtfmtStyle.KOTLIN_STYLE
            val injectHookTask = ext.injectHookTaskPath.orNull ?: "app:clean"

            // Configure all subprojects
            allprojects {
                // Apply ktfmt plugin and configure based on chosen style
                apply(plugin = "com.ncorti.ktfmt.gradle")
                extensions.configure<KtfmtExtension> {
                    when (ktfmtStyle) {
                        KtfmtStyle.GOOGLE_STYLE -> googleStyle()
                        KtfmtStyle.KOTLIN_STYLE -> kotlinLangStyle()
                    }
                }

                // Apply detekt plugin and configure
                apply(plugin = "io.gitlab.arturbosch.detekt")
                extensions.configure<DetektExtension> {
                    if (composeEnabled) {
                        // Use a specific config file for Compose projects
                        config.setFrom(file("$projectDir/config/detekt-config.yml"))
                        buildUponDefaultConfig = true
                    }
                    allRules = false // Don't enable all rules
                    autoCorrect = true // Enable auto-correction
                    parallel = true // Run detekt in parallel
                }

                // Add Compose detekt rules if Compose is enabled
                if (composeEnabled) {
                    dependencies { add("detektPlugins", "io.nlopez.compose.rules:detekt:0.4.5") }
                }
            }

            // Configure detekt tasks for reporting
            tasks.withType<Detekt>().configureEach {
                reports {
                    // Enable the generation of an HTML report
                    html.required.set(true)

                    // Enable the generation of a TXT report
                    txt.required.set(true)

                    // Enable the generation of a Markdown (MD) report
                    md.required.set(true)
                }
            }

            // Task to copy the detekt config
            tasks.register<Copy>("copyDetektConfig") {
                description =
                    "Copies the detekt config from the plugin's directory to the app/config folder."
                group = "detektConfig"

                if (detektConfigResource != null) {
                    // Use a temporary file to handle the resource stream
                    val tempDir = Files.createTempDirectory("detekt-config-temp").toFile()
                    val tempFile = File(tempDir, "detekt-config.yml")
                    try {
                        Files.copy(
                            detektConfigResource,
                            tempFile.toPath(),
                            StandardCopyOption.REPLACE_EXISTING)
                        from(tempFile)
                        logger.log(
                            LogLevel.DEBUG, "Copying detekt config from: ${tempFile.absolutePath}")
                    } catch (e: Exception) {
                        logger.log(
                            LogLevel.ERROR, "Failed to copy detekt config resource: ${e.message}")
                    } finally {
                        detektConfigResource.close() // Close the resource stream
                    }
                } else {
                    logger.log(LogLevel.ERROR, "detekt config resource not found in the plugin.")
                }

                into("${rootDir}/app/config/")
                logger.log(LogLevel.DEBUG, "Copying detekt config to: ${rootDir}/app/config/")
            }

            // Task to copy the pre-commit hook script
            tasks.register<Copy>("copyGitHooks") {
                description = "Copies the git hooks from the plugin's directory to the .git folder."
                group = "gitHooks"

                if (preCommitScriptResource != null) {
                    // Use a temporary file to handle the resource stream
                    val tempDir = Files.createTempDirectory("git-hooks-temp").toFile()
                    val tempFile = File(tempDir, "pre-commit")
                    try {
                        Files.copy(
                            preCommitScriptResource,
                            tempFile.toPath(),
                            StandardCopyOption.REPLACE_EXISTING)
                        from(tempFile)
                        logger.log(
                            LogLevel.DEBUG, "Copying git hooks from: ${tempFile.absolutePath}")
                    } catch (e: Exception) {
                        logger.log(
                            LogLevel.ERROR, "Failed to copy git hooks resource: ${e.message}")
                    } finally {
                        preCommitScriptResource.close() // Close the resource stream
                    }
                } else {
                    logger.log(LogLevel.ERROR, "Git hooks resource not found in the plugin.")
                }

                into("${rootDir}/.git/hooks/")
                logger.log(LogLevel.DEBUG, "Copying git hooks to: ${rootDir}/.git/hooks/")
                if (composeEnabled) {
                    dependsOn("copyDetektConfig")
                }
            }

            // Task to install (make executable) the pre-commit hook
            tasks.register<Exec>("installGitHooks") {
                description = "Installs the pre-commit git hooks."
                group = "gitHooks"
                workingDir = rootDir
                commandLine = listOf("chmod")
                args("-R", "+x", ".git/hooks/")
                dependsOn("copyGitHooks")
                doLast { logger.info("Git hook installed successfully.") }
            }

            // Make the specified build task depend on installing the git hooks
            afterEvaluate { tasks.getByPath(injectHookTask).dependsOn(":installGitHooks") }
        }
    }
}

Next, we will add the pre-commit script and detekt configuration files.

Adding Pre-Commit Script and detekt Configuration

For our plugin to work, we need to include the pre-commit script and detekt configuration file in our plugin resources. We created these files in the previous blogs, so we will just share the code for them, for more information please refer to the blogs mentioned at the top.

Create the pre-commit script: Inside the src/main/resources/scripts directory, create a file named pre-commit with the following content:

#!/bin/bash
set -e

echo "
===================================
|  Formatting code with ktfmt...  |
==================================="

if ! ./gradlew --quiet --no-daemon ktfmtFormat --stacktrace; then
    echo "Ktfmt failed"
    exit 1
fi

echo "
=======================
|  Running detekt...  |
======================="

if ! ./gradlew --quiet --no-daemon detekt --stacktrace -PdisablePreDex; then
    echo "detekt failed"
    exit 1
fi

if ! command -v git &> /dev/null; then
    echo "Git could not be found"
    exit 1
fi

git add -u

exit 0

Create the pre-commit script: Inside the src/main/resources directory, create a file named detekt-config.yml with the following content:

Compose:
 ComposableAnnotationNaming:
   active: true
 ComposableNaming:
   active: true
 ComposableParamOrder:
   active: true
 CompositionLocalAllowlist:
   active: true
   allowedCompositionLocals: LocalCustomColorsPalette,LocalCustomTypography
 CompositionLocalNaming:
   active: true
 ContentEmitterReturningValues:
   active: true
 DefaultsVisibility:
   active: true
 LambdaParameterInRestartableEffect:
   active: true
 ModifierClickableOrder:
   active: true
 ModifierComposable:
   active: true
 ModifierMissing:
   active: true
 ModifierNaming:
   active: true
 ModifierNotUsedAtRoot:
   active: true
 ModifierReused:
   active: true
 ModifierWithoutDefault:
   active: true
 MultipleEmitters:
   active: true
 MutableParams:
   active: true
 MutableStateParam:
   active: true
 PreviewAnnotationNaming:
   active: true
 PreviewPublic:
   active: true
 RememberMissing:
   active: true
 RememberContentMissing:
   active: true
 UnstableCollections:
   active: true
 ViewModelForwarding:
   active: true
 ViewModelInjection:
   active: true

naming:
 FunctionNaming:
   ignoreAnnotated: [ 'Composable' ]
 TopLevelPropertyNaming:
   constantPattern: '[A-Z][A-Za-z0-9]*'

complexity:
 LongParameterList:
   functionThreshold: 15
   ignoreDefaultParameters: true

 LongMethod:
   active: false

style:
 MagicNumber:
   active: false
 UnusedPrivateMember:
   ignoreAnnotated: [ 'Preview' ]

And that's it, you implemented a Gradle plugin that will apply ktfmt and detekt, neccessary configuration and a pre-commit hook on any project. By doing this you avoided repeating the project for every project. But, before you can apply it to your projects, there is one thing left to do and that is the publishing of your plugin.

Publishing the Gradle Plugin to a private repository

After implementing the plugin, the final step is to publish it so you can use it across your projects. This process involves setting up your project for publication and configuring the necessary details for publishing to a repository. We will cover publishing to a private Maven repository. If you want to publish your plugin publicly, please check the notes at the beginning of this blog.

Step 1: Check Requirements

Ensure the maven-publish plugin is applied in your build.gradle.kts. This plugin provides the necessary tasks and configurations to publish your artifacts to a Maven repository. Also, make sure you have set up the gradlePlugin block:

plugins {
    ...
    `maven-publish`
}

gradlePlugin {
    plugins {
        create("precommit") {
            id = "org.example.precommit"
            displayName = "PreCommit"
            description = "Gradle plugin that adds a pre-commit hook to your project that runs detekt and ktfmt"
            tags.set(listOf("pre-commit", "kotlin", "detekt", "ktfmt"))
            implementationClass = "org.example.PreCommitPlugin"
        }
    }
}

Step 2: Prepare for Publication

Ensure your project is set up with the necessary metadata and credentials to publish the plugin. To tell the maven-publish plugin where to publish the plugin, you need to set up the publishing block. Define the URL to your Maven repository and the accompanying credentials. Since we are working with sensitive information, store these inside the gradle.properties file, which should be inside the .gitignore file to avoid leaking credentials. Your gradle.properties should look like this:

username=your_username
password=your_password
url=https://nexus.example.org/repository/kotlin-packages

Set up the publishing block by adding the following code to your build.gradle.kts file:

publishing {
    repositories {
        maven {
            credentials {
                username = project.properties["username"].toString()
                password = project.properties["password"].toString()
            }
            url = URI(project.properties["url"].toString())
        }
    }
}

Step 3: Publish the Plugin

With everything configured, you can now publish your plugin. Use the following command to publish the plugin to your repository:

./gradlew publish

This command will build the plugin and upload it to the specified Maven repository. Ensure you have network access and the correct credentials configured.

Step 4: Using the Published Plugin

Since you published your plugin to the private Maven repository, you need to provide the URL and credentials so it can be downloaded into your projects. If you published your plugin publicly or to the local Maven repository, you can skip this step. Inside your project, create a local.properties file and add it to .gitignore. Add the following contents to local.properties:

username=your_username
password=your_password
url=https://nexus.example.org/repository/kotlin-packages

Next, define the Maven repository inside settings.gradle.kts:

repositories {
    ...
    val localProperties = java.util.Properties().apply {
        load(java.io.FileInputStream(File(rootDir, "local.properties")))
    }

    maven {
        credentials {
            username = localProperties.getProperty("username").toString()
            password = localProperties.getProperty("password").toString()
        }
        url = java.net.URI(localProperties.getProperty("url").toString())
    }
}

After adding the Maven URL and credentials, you can apply the plugin inside your project by including it in the top-level build.gradle.kts file:

plugins {
    ...
    id("org.example.precommit") version "0.0.1" // The plugin version we defined in the plugin build.gradle.kts
}

preKommitConfig {
    composeEnabled = false
    ktfmtStyle = KtfmtStyle.KOTLIN_STYLE
    injectHookTaskPath = "app:preBuild"
}

By doing this, you apply ktfmt and detekt to all of your project modules, ensuring consistent code quality and code styling across your entire codebase.

Conclusion

By developing a custom Gradle plugin, we've streamlined the process of integrating ktfmt and detekt across multiple projects. This plugin ensures consistent code formatting and static analysis, reducing setup time and improving code quality. This blog covered the essential steps to create, configure, and publish a Gradle plugin that automates the integration of ktfmt and detekt, along with setting up a pre-commit hook. With this plugin, you can ensure that all your projects follow the same standards with minimal effort.

References:

Enhancing Code Quality with detekt for Static Analysis

Marko Pavičić — Tue, 16 Jul 2024 09:02:18 +0000

When our team began migrating to Jetpack Compose, we wanted to avoid common mistakes due to our limited expertise. We discovered detekt, a tool that provides static code analysis for Kotlin projects, and compose-rules, which integrates Jetpack Compose-specific checks into detekt. We also wanted to implement these tools into the pre-commit hook we implemented in the previous blog post (dev.to, Medium).

This blog will guide you through the steps to integrate detekt into your projects and fine-tune its configuration to optimize performance for Jetpack Compose projects.

Let's start with a short introduction to static code analysis and its purpose.

Introduction to Static Code Analysis

Static code analysis helps in identifying potential issues, enforcing coding standards, and ensuring code quality and maintainability. By catching issues early in the development process, it can save time and effort, ultimately leading to more robust and reliable software.

Our tool of choice was detekt, here's a quick overview of it.

Introduction to detekt

detekt is a static code analysis tool for Kotlin projects. We chose it for our projects due to its comprehensive set of rules, ease of integration, and active community support. It offers features such as customizable rules, reporting capabilities, and integration with popular build tools, making it a valuable addition to our development workflow.

Let's set it up in our project.

Setting Up detekt

To implement detekt into your projects, simply add the detekt dependency to your Top-level build.gradle or build.gradle.kts file:

plugins {
    ...
    id("io.gitlab.arturbosch.detekt") version("1.23.6")  // Replace with latest version
}

After adding the detekt Gradle plugin, here's how you can configure it to better match your requirements.

Configuration

detekt offers a lot of customizability, which allowed us to use it effectively on our Jetpack Compose projects. You can fine-tune the rules, console reports, output reports, and similar.

When you use it on Jetpack Compose projects, it requires some additional configuration via the detekt-config.yml file. While researching detekt and its configuration, we also came across compose-rules which came to rescue when we were migrating from XML to Jetpack Compose. From their overview:

The Compose Rules is a set of custom Ktlint / detekt rules to ensure that your composables don't fall into common pitfalls, that might be easy to miss in code reviews.

For detekt to work properly and efficiently on Jetpack Compose projects, please follow these steps:

Navigate to your project's root directory, e.g., ~/projects/SampleProject/
Create a new directory named configs and inside it, create a new file named detekt-config.yml

Your file tree should look like this when viewing your project from the Project view:
Open the file with a text editor and paste the configuration found here

Add the Jetpack Compose-specific detekt configuration at the end of the file

...
naming:
 FunctionNaming:
   ignoreAnnotated: [ 'Composable' ]
 TopLevelPropertyNaming:
   constantPattern: '[A-Z][A-Za-z0-9]*'

complexity:
 LongParameterList:
   functionThreshold: 15
   ignoreDefaultParameters: true

 LongMethod:
   active: false

style:
 MagicNumber:
   active: false
 UnusedPrivateMember:
   ignoreAnnotated: [ 'Preview' ]

This configuration is added to avoid false positives, for example, the default functionThreshold value inside the LongParameterList rule is 6 which can easily be exceeded with complex Composable functions.

The complete detekt-config.yml should look like this:

Compose:
 ComposableAnnotationNaming:
   active: true
 ComposableNaming:
   active: true
   # -- You can optionally disable the checks in this rule for regex matches against the composable name (e.g. molecule presenters)
   # allowedComposableFunctionNames: .*Presenter,.*MoleculePresenter
 ComposableParamOrder:
   active: true
   # -- You can optionally have a list of types to be treated as lambdas (e.g. typedefs or fun interfaces not picked up automatically)
   # treatAsLambda: MyLambdaType
 CompositionLocalAllowlist:
   active: true
   allowedCompositionLocals: LocalCustomColorsPalette,LocalCustomTypography
   # -- You can optionally define a list of CompositionLocals that are allowed here
   # allowedCompositionLocals: LocalSomething,LocalSomethingElse
 CompositionLocalNaming:
   active: true
 ContentEmitterReturningValues:
   active: true
   # -- You can optionally add your own composables here
   # contentEmitters: MyComposable,MyOtherComposable
 DefaultsVisibility:
   active: true
 LambdaParameterInRestartableEffect:
   active: true
   # -- You can optionally have a list of types to be treated as lambdas (e.g. typedefs or fun interfaces not picked up automatically)
   # treatAsLambda: MyLambdaType
 ModifierClickableOrder:
   active: true
   # -- You can optionally add your own Modifier types
   # customModifiers: BananaModifier,PotatoModifier
 ModifierComposable:
   active: true
   # -- You can optionally add your own Modifier types
   # customModifiers: BananaModifier,PotatoModifier
 ModifierMissing:
   active: true
   # -- You can optionally control the visibility of which composables to check for here
   # -- Possible values are: `only_public`, `public_and_internal` and `all` (default is `only_public`)
   # checkModifiersForVisibility: only_public
   # -- You can optionally add your own Modifier types
   # customModifiers: BananaModifier,PotatoModifier
 ModifierNaming:
   active: true
   # -- You can optionally add your own Modifier types
   # customModifiers: BananaModifier,PotatoModifier
 ModifierNotUsedAtRoot:
   active: true
   # -- You can optionally add your own composables here
   # contentEmitters: MyComposable,MyOtherComposable
   # -- You can optionally add your own Modifier types
   # customModifiers: BananaModifier,PotatoModifier
 ModifierReused:
   active: true
   # -- You can optionally add your own Modifier types
   # customModifiers: BananaModifier,PotatoModifier
 ModifierWithoutDefault:
   active: true
 MultipleEmitters:
   active: true
   # -- You can optionally add your own composables here that will count as content emitters
   # contentEmitters: MyComposable,MyOtherComposable
   # -- You can add composables here that you don't want to count as content emitters (e.g. custom dialogs or modals)
   # contentEmittersDenylist: MyNonEmitterComposable
 MutableParams:
   active: true
 MutableStateParam:
   active: true
 PreviewAnnotationNaming:
   active: true
 PreviewPublic:
   active: true
 RememberMissing:
   active: true
 RememberContentMissing:
   active: true
 UnstableCollections:
   active: true
 ViewModelForwarding:
   active: true
   # -- You can optionally use this rule on things other than types ending in "ViewModel" or "Presenter" (which are the defaults). You can add your own via a regex here:
   # allowedStateHolderNames: .*ViewModel,.*Presenter
   # -- You can optionally add an allowlist for Composable names that won't be affected by this rule
   # allowedForwarding: .*Content,.*FancyStuff
 ViewModelInjection:
   active: true
   # -- You can optionally add your own ViewModel factories here
   # viewModelFactories: hiltViewModel,potatoViewModel

naming:
 FunctionNaming:
   ignoreAnnotated: [ 'Composable' ]
 TopLevelPropertyNaming:
   constantPattern: '[A-Z][A-Za-z0-9]*'

complexity:
 LongParameterList:
   functionThreshold: 15
   ignoreDefaultParameters: true

 LongMethod:
   active: false

style:
 MagicNumber:
   active: false
 UnusedPrivateMember:
   ignoreAnnotated: [ 'Preview' ]

This configuration enables the compose-rules and modifies some of detekt's default rule sets and their configuration options to avoid incorrect detection.

Save the file and close the editor

At your Top-level build.gradle or build.gradle.kts add the following code:

   ...
   allprojects {
       ...
       apply(plugin = "io.gitlab.arturbosch.detekt")

       // Configure the detekt plugin
       detekt {
           // Set the detekt configuration from previous steps
           config.setFrom(file("$projectDir/config/detekt-config.yml"))

           // Build upon the default detekt configuration, instead of replacing it
           buildUponDefaultConfig = true

           // Do not activate all detekt rules
           allRules = false

           // Enable automatic correction of issues found by detekt
           autoCorrect = true

           // Run detekt in parallel mode for better performance
           parallel = true
       }
   }

The code snippet above configures the detekt plugin to build upon the default configuration and apply the configuration we defined inside the detekt-config.yml file. We set allRules to false so unstable rules aren't applied. autoCorrect is set to true so that if a rule supports auto correction it is applied to the code, parallel ensures parallel compilation and analysis of source files.

...
// Configure each detekt task
tasks.withType<Detekt>().configureEach {
    reports {
        // Enable the generation of an HTML report
        html.required.set(true)
        html.outputLocation.set(file("build/reports/detekt.html"))

        // Enable the generation of a TXT report
        txt.required.set(true)
        txt.outputLocation.set(file("build/reports/detekt.txt"))

        // Enable the generation of a Markdown (MD) report
        md.required.set(true)
        md.outputLocation.set(file("build/reports/detekt.md"))
    }
}

The code snippet above cofigures all detekt tasks to generate HTML, TXT and Markdown reports and to save them in the build/reports directory.

At your Top-level build.gradle or build.gradle.kts add the following code to apply the compose-rules detekt rule set:

   allprojects {
   ...
   dependencies {
       ...
       detektPlugins("io.nlopez.compose.rules:detekt:0.4.4") // Replace with latest version
   }
}

Sync your project with Gradle Files

These steps provide you with somewhat of a basic setup when using detekt on Jetpack Compose projects, feel free to modify it and try out different configurations that better suit your needs. For a complete list of configuration fields, please refer to: Options for detekt configuration closure and detekt Configuration File.

After you implemented and configured detekt to run on your project, it's time to run it!

Running detekt

After implementing the necessary dependencies for detekt, applying the configuration, and syncing your project with Gradle Files, you can run the detekt Gradle task. That can be done by:

The Gradle tool window:
- Open the Gradle tool window
- Navigate to Tasks/verification
- Double-click on the detekt task (or right-click and click on Run)

The terminal:
- Open the Terminal window inside Android Studio
- Run the following command: ./gradlew detekt

The task failed because code issues were detected, we will dive deeper into reading these reports in a section below.

Since we implemented a pre-commit hook for ktmft we will make use of it for detekt as well.

Adding detekt to the pre-commit hook

To avoid having to run this task manually, we can make use of the pre-commit hook we implemented in the previous blog in the series:

Navigate to your project's root directory, e.g., ~/projects/SampleProject/
Toggle hidden files and folders visibility [Windows, MacOS, Linux]
Navigate to rootProjectDir/.git/hooks and open the file named pre-commit, which we created previously with a text editor

Open the file with a text editor and add the following code:

... 
echo "
=======================
|  Running detekt...  |
======================="

# Run detekt static code analysis with Gradle
if ! ./gradlew --quiet --no-daemon detekt --stacktrace -PdisablePreDex; then
   echo "detekt failed"
   exit 1
fi
...

The complete script should now look like this:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status
set -e

echo "
===================================
|  Formatting code with ktfmt...  |
==================================="

# Run ktfmt formatter on the specified files using Gradle
if ! ./gradlew --quiet --no-daemon ktfmtPrecommitFormat; then
   echo "Ktfmt failed"
   exit 1
fi

echo "
=======================
|  Running detekt...  |
======================="

# Run detekt static code analysis with Gradle
if ! ./gradlew --quiet --no-daemon detekt --stacktrace -PdisablePreDex; then
   echo "detekt failed"
   exit 1
fi

# Check if git is available
if ! command -v git &> /dev/null; then
   echo "git could not be found"
   exit 1
fi

# Add all updated files to the git staging area
git add -u

# Exit the script successfully
exit 0

Save the file and close the editor

After we ran detekt, we found some issues, now we will dive deeper into reading those reports.

Inspecting detekt reports

When we configured detekt we enabled HTML, text and Markdown reports. We will focus on the HTML report, but other output formats are very similar.

detekt found issues when we first ran it in the section above, let's see that report in HTML:

Metrics

number of properties
number of functions
number of classes
number of packages
number of kt files

Complexity Report

lines of code (loc): The total number of lines in the codebase, including all code, comments, and whitespace. This gives an overall sense of the size of the project.
source lines of code (sloc): This metric includes only the lines that contain actual source code, excluding comments and whitespace. It's a more accurate representation of the amount of code written.
logical lines of code (lloc): This includes lines of code that represent executable statements, ignoring comments, whitespace, and block delimiters. It provides a clearer picture of the code's functional size.
comment lines of code (cloc): The total number of lines that contain comments. This helps in understanding the documentation level within the code.
cyclomatic complexity (mcc): A measure of the code's complexity, calculated by counting the number of linearly independent paths through the code. Higher values indicate more complex code, which is harder to test and maintain.
cognitive complexity: This measures how difficult the code is to understand. Unlike cyclomatic complexity, which focuses on the structure, cognitive complexity considers the human aspect of code comprehension.
number of total code smells: Code smells are indicators of potential problems in the code. This metric counts all identified code smells, which can help in prioritizing refactoring efforts.
comment source ratio: This is the ratio of comment lines to source lines of code (cloc/sloc). A higher ratio typically indicates better-documented code.
mcc per 1,000 lloc: This normalizes cyclomatic complexity by logical lines of code, showing how complex the code is on a per 1,000 lines basis. It helps compare complexity across different-sized projects.
code smells per 1,000 lloc: This metric normalizes the number of code smells by logical lines of code, providing a density measure that helps in identifying areas that may need more attention regardless of the project's size.

Findings

The Findings section in a detekt report identifies specific issues in the codebase that need attention. These issues are categorized by type and include details such as location, message, and relevant code snippets.

Total: The total number of findings detected by detekt, indicating the overall number of issues in the codebase.

[Category]

Each category represents a specific type of issue detected. Examples of categories include "Compose", "style", "formatting", etc.

RuleName: Each rule represents a specific coding standard or best practice that the code should adhere to.
- Documentation: A link to detailed documentation about the rule. This documentation provides more in-depth information about why the rule exists, examples of violations, and how to resolve them.
- Location: This indicates the exact file and line number where the issue is found. It helps developers quickly locate the problematic code.
- Message: A description of the issue, explaining what is wrong and why it should be fixed. This often includes guidance on how to correct the problem.
- Code Snippet: A portion of the code where the issue is detected is highlighted to give context to the finding.

The finding above comes from the compose-rules rule set and the findings below from detekt's rule set.

Some issues detekt reports could be acceptable to you, and you don't want to change your code. To avoid detekt reporting these issues, you can suppress them, which we will describe below.

Suppressing Issues

Since we implemented detekt in a pre-commit hook that will block the commit if there are any issues, you will quickly encounter an issue that blocks the commit, but you and the team have no concern with it.

To suppress issues in detekt you can add the @Suppress annotation.
Inside the values field of the @Suppress annotation, you need to write the RuleName

Here's an example:

@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
    BlogSampleTheme { Greeting("Android") }
}

This block of code produces the following issue:

PreviewPublic: 1 Composables annotated with @Preview that are used only for previewing the UI should not be public.

To suppress this issue you can add the @Suppress annotation like this:

@Suppress("PreviewPublic")
@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
    BlogSampleTheme { Greeting("Android") }
}

You can also suppress issues at the file level. In the previous example, you could have added the following line at the very top of the file: @file:Suppress("PreviewPublic")

Benefits and Challenges

Since integrating detekt, we have observed several benefits:

Migration from XML to Jetpack Compose: Our migration process has been greatly impacted by implementing detekt, the migration and learning process were accelerated, and some common mistakes were caught on time.
Improved Code Quality: detekt has helped us identify and address code smells, resulting in cleaner and more maintainable code.
Consistent Standards: By enforcing coding standards, detekt ensures that all team members adhere to the same guidelines, improving code consistency.
Enhanced Learning: The feedback provided by detekt has been instrumental in helping developers learn and adopt best practices.

However, we also faced some challenges:

Configuration Complexity: Initial configuration and customization of detekt to suit our specific needs required some effort and research.
False Positives: In some cases, detekt flagged issues that were not necessarily problematic, requiring us to fine-tune the rules or suppress them.

Conclusion

Thank you for taking the time to read this post. We hope it has provided valuable insights into the benefits of using detekt and inspired you to implement it in your projects.

Initially, we implemented detekt on a single project. This setup, described above, involved configuring rules and integrating it into our build process. However, when we moved to implement detekt on another project, we quickly realized we needed to go through the entire configuration process again for each new project. This repetition highlighted the need for a more streamlined and reusable setup method.

We will address this issue in the next blog post in this series. In the meantime check out our Barrage blog for more interesting topics.

Integrating Code Formatting into Your Android Projects

Marko Pavičić — Mon, 01 Jul 2024 10:03:02 +0000

This is the first blog in the series where we will share our journey of implementing and automating code formatting and static code analysis in Android projects.

Motivation for the Series

In our projects, we initially relied on IntelliJ's Reformat Code feature with the default code style settings. This helped maintain the readability and consistency of our codebase.

Since it was a manual step it was easy to forget after every change. And if we weren't diligent, we'd end up with a messy project with code all over the place, remembering to reformat code added extra overhead to the development process.

To address these issues, we sought automated solutions to ensure consistent formatting. We implemented a pre-commit hook script that runs ktfmt for Kotlin code formatting.

When our team began migrating to Jetpack Compose, we wanted to avoid common mistakes due to our limited expertise. We discovered detekt and compose-rules for static code analysis which was also added to our pre-commit hook.

Integrating this pre-commit hook maintained a high code quality and consistency across the team, streamlined our workflow, and reduced manual overhead. Overall, it significantly improved our development process by enforcing consistent code formatting and static analysis practices effortlessly.

Since this proved incredibly useful for us, we decided to share our experience in the following article series.

Series Overview

This series is divided into the following parts, each focusing on a specific aspect of our process:

Integrating Code Formatting into Your Android Projects
- An introduction to the importance of code formatting and how to integrate tools like ktfmt. We’ll cover the benefits of code formatting and provide a step-by-step guide to setting up ktfmt in your project which will automatically run before each commit using a pre-commit hook.
Enhancing Code Quality with detekt for Static Analysis
- A deep dive into using detekt for static code analysis in Android projects. This article will explore how detekt helps in identifying code smells, enforcing coding standards, and improving overall code quality. To automate the static analysis project detekt will be added to our pre-commit hook
Developing a Custom Gradle Plugin for Formatting and Static Analysis
- Step-by-step guide to creating and publishing a custom Gradle plugin that integrates both ktfmt and detekt and applies our pre-commit hook. This plugin will ensure that code formatting and static analysis are consistently applied and automatically ran on each commit across all your projects, simplifying the setup process for new projects.

By the end of this series, you'll have the tools and knowledge to maintain a clean, consistent, and high-quality codebase in your Android projects.

Let's look into integrating ktfmt first.

Integrating Code Formatting into Your Android Projects

This blog will take you through the implementation of code formatting with ktfmt. We will explain its purpose and present the benefits we discovered after the integration.

Firstly, a brief introduction to ktfmt.

Introduction to ktfmt

ktfmt is a tool developed by Facebook that pretty-prints (formats) Kotlin code based on google-java-format. It always produces the same result, regardless of how the code looks initially, allowing developers to focus on the essence of their code.

One of the key features of ktfmt is its non-customizability, which is designed to promote consistency. Initially, we used ktlint, but after research and testing, we found ktfmt to be more consistent and simpler to set up. This comment on Reddit also highlights the reliability of ktfmt: Reddit Comment. You can also find the differences in the official ktfmt readme.

Let's set it up in our project.

Setting Up ktfmt

To integrate ktfmt, you can use the command-line interface (CLI) tool, but for this guide, we will focus on using the ktfmt Gradle plugin.

Simply apply the latest plugin version inside your Top-level build.gradle or build.gradle.kts file, sync your project, and you're good to go.

plugins {
    ...
    id("com.ncorti.ktfmt.gradle") version("0.18.0") // Replace with latest version
}

Now that you have the plugin integrated, let's look into configuring it for your specific use case.

Configuring ktfmt

Since ktfmt isn't very customizable, it means it's easy to adhere to a strict formatting system. With complex customization options, you can fall into the trap of having too many custom rules. This can hurt your codebase in the long run, as more and more rules mean there is less consistency overall.

The plugin gives you the option to choose which code style you want to use. The main difference between the code styles is the number of spaces used for block indentations.

For our purposes, we decided to use the Kotlin Lang code style (4 space block indentation), but feel free to try to use any one you prefer.

To configure the ktfmt Gradle plugin to use the Kotlin Lang code style, add the following code to your Top-level build.gradle or build.gradle.kts file:

allprojects {
    ...
    apply(plugin = "com.ncorti.ktfmt.gradle")
    ktfmt { // 1
        kotlinLangStyle() // 2
    }
}

In the snippet above, we did the following:

Opened the configuration block of ktfmt. All of the configuration goes within this block. Some configuration examples are line break width, various indents, import handling, and similar. The complete list of configurable fields can be found here.
Applied the Kotlin Lang style, feel free to apply any code style you like.

Now that you've applied the plugin, you can finally run the formatting!

Running ktfmtFormat

After you've applied the plugin and synced your project with Gradle plugins you can run the ktfmtFormat Gradle task.
That can be done from:

The Gradle tool window:
- Open the Gradle tool window
- Navigate to Tasks/formatting
- Double click on the ktfmtFormat task (or right-click and click on Run)

The terminal:
- Open the Terminal window inside Android Studio
- Run the following command: ./gradlew ktfmtFormat

So far, we have implemented a consistent code formatting style, but we haven't fixed the main problem, having to manually reformat the code.

To fix this issue we will implement a pre-commit hook for our project.

Creating a pre-commit hook

To avoid having to manually run the ktfmtFormat Gradle task before each commit, we've decided to implement a pre-commit hook script.

Firstly, make sure Git is set up for your project before you continue with the next steps.

Navigate to your project's root directory, e.g., ~/projects/SampleProject/
Toggle hidden files and folders visibility [Windows, MacOS, Linux]
Navigate to rootProjectDir/.git/hooks and create a new file named pre-commit without an extension

Open the file with a text editor and paste the following code:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status
set -e

echo "
===================================
|  Formatting code with ktfmt...  |
==================================="

# Run ktfmt formatter on the specified files using Gradle
if ! ./gradlew --quiet --no-daemon ktfmtFormat; then
    echo "Ktfmt failed"
    exit 1
fi

# Check if git is available
if ! command -v git &> /dev/null; then
    echo "git could not be found"
    exit 1
fi

# Add all updated files to the git staging area
git add -u

# Exit the script successfully
exit 0

Save the file and close the editor
Add the execution permission for your pre-commit hook script, on Mac, open the Terminal, navigate to the rootProjectDir directory and run the following command: chmod +x .git/hooks/*

What this does is run the code from the pre-commit script before each commit. If any of the commands failed, the commit would be aborted. Currently, the pre-commit hook we created runs the ktfmtFormat Gradle task, but it will be expanded in the following parts of this series.

Try initiating a commit; your project's files should be automatically formatted.

By default, this script will run the formatting on all .kt and .kts project files. You can run the formatting on specific files only, here's an example of how you can run formatting on staged files only.

Applying Formatting only on specific project files

If you want to run the script on only some of the files, you can take advantage of the ktfmt --include-only parameter.

To do that, go to your Top-level build.gradle or build.gradle.kts file and paste the following code:

tasks.register<KtfmtFormatTask>("ktfmtPrecommitFormat") {
    group = "formatting"
    description = "Runs ktfmt on kotlin files in the project"
    source = project.fileTree(rootDir).apply { include("**/*.kt", "**/*.kts") }
}

The code snippet above registers a new Gradle task named ktfmPrecommitFormat, we defined the tasks group and added a description. We've set the source to include all of the .kt and .kts files inside the project

Here's how you can implement a pre-commit hook script that runs ktfmt only on staged git files:

Reading staged files and processing them

ktfmt takes in a --include-only argument which is a String of joint file names which we want to format separated by a semicolon (;)

echo "
===================================
|  Formatting code with ktfmt...  |
==================================="

# Get the list of staged files from git, filtering by their status and paths
git_output=$(git --no-pager diff --name-status --no-color --cached)
file_array=()
file_names=()

# Process each line of git output
while IFS= read -r line; do
   status=$(echo "$line" | awk '{print $1}')
   file=$(echo "$line" | awk '{print $2}')
   # Include only .kt and .kts files that are not marked for deletion
   if [[ "$status" != "D" && "$file" =~ \.kts$|\.kt$ ]]; then
       # Extract relative paths starting from 'src/'
       relative_path=$(echo "$file" | sed 's/.*\(src\/.*\)/\1/')
       file_array+=("$relative_path")
       file_names+=("$file")
   fi
done <<< "$git_output"

# Join file array into a semicolon-separated string
files_string=$(IFS=";"; echo "${file_array[*]}")

Formatting specified files after processing

# Run ktfmt formatter on the specified files
./gradlew --quiet --no-daemon ktfmtPrecommitFormat --include-only="$files_string"
ktfmtStatus=$?

# If ktfmt fails, print a message and exit with the failure code
if [ "$ktfmtStatus" -ne 0 ]; then
    echo "Ktfmt failed with exit code $ktfmtStatus"
    exit 1
fi

Re-add the modified files to Git

When a pre-commit hook modifies files (e.g., formats them), the modified versions of these files need to be staged again for commit. This is because the files are initially staged (added to the index) before the hook runs. If the hook changes these files (e.g., through formatting), the changes are made in the working directory but not in the index.
```
# Check if git is available
if ! command -v git &> /dev/null; then
    echo "git could not be found"
    exit 1
fi

# Re-add the formatted files to the git index with the original paths
for i in "${!file_array[@]}"; do
    file=${file_names[$i]}
    if [ -f "$file" ]; then
        git add "$file"
    fi
done
```

The complete script file should look like this:

echo "
===================================
|  Formatting code with ktfmt...  |
==================================="

# Get the list of staged files from git, filtering by their status and paths
git_output=$(git --no-pager diff --name-status --no-color --cached)
file_array=()
file_names=()

# Process each line of git output
while IFS= read -r line; do
    status=$(echo "$line" | awk '{print $1}')
    file=$(echo "$line" | awk '{print $2}')
    # Include only .kt and .kts files that are not marked for deletion
    if [[ "$status" != "D" && "$file" =~ \.kts$|\.kt$ ]]; then
        # Extract relative paths starting from 'src/'
        relative_path=$(echo "$file" | sed 's/.*\(src\/.*\)/\1/')
        file_array+=("$relative_path")
        file_names+=("$file")
    fi
done <<< "$git_output"

# Join file array into a semicolon-separated string
files_string=$(IFS=";"; echo "${file_array[*]}")

# Run ktfmt formatter on the specified files
./gradlew --quiet --no-daemon ktfmtPrecommitFormat --include-only="$files_string"
ktfmtStatus=$?

# If ktfmt fails, print a message and exit with the failure code
if [ "$ktfmtStatus" -ne 0 ]; then
    echo "Ktfmt failed with exit code $ktfmtStatus"
    exit 1
fi

# Check if git is available
if ! command -v git &> /dev/null; then
    echo "git could not be found"
    exit 1
fi

# Re-add the formatted files to the git index with the original paths
for i in "${!file_array[@]}"; do
    file=${file_names[$i]}
    if [ -f "$file" ]; then
        git add "$file"
    fi
done

Comparing Non-Formatted and Formatted Code

Here is an example of how ktfmt can transform your code.

Non-Formatted Code:

@Composable
fun ScreenContent(
    modifier:Modifier=Modifier) {
    var showGreetingText by remember {mutableStateOf(true)}
    Column(
        modifier =modifier.fillMaxSize().padding(20.dp),verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        if(showGreetingText) Greeting(name="Android", modifier = Modifier.align(Alignment.CenterHorizontally))
        Button(
            onClick={showGreetingText=!showGreetingText }, modifier = Modifier.align(Alignment.CenterHorizontally)
        ) { Text(text=if (showGreetingText) "Hide greeting text" else "Show greeting text") }
    }
}

Formatted Code:

@Composable
fun ScreenContent(modifier: Modifier = Modifier) {
    var showGreetingText by remember { mutableStateOf(true) }
    Column(
        modifier = modifier.fillMaxSize().padding(20.dp),
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        if (showGreetingText)
            Greeting(name = "Android", modifier = Modifier.align(Alignment.CenterHorizontally))
        Button(
            onClick = { showGreetingText = !showGreetingText },
            modifier = Modifier.align(Alignment.CenterHorizontally)
        ) {
            Text(text = if (showGreetingText) "Hide greeting text" else "Show greeting text")
        }
    }
}

As you can see, the formatted code is much cleaner and easier to read, which helps in maintaining the codebase and avoiding errors.

Benefits of Integrating ktfmt

Integrating ktfmt into our projects has provided several benefits:

Consistency: The codebase is consistently formatted, which enhances readability and maintainability.
Reduced Human Error: Automated formatting reduces the likelihood of human error, ensuring that the code adheres to a standard style.
Focus on Code Essence: Developers can focus more on the logic and functionality of the code rather than worrying about formatting.

Resources

To dive deeper into ktfmt, check out the following resources:

Conclusion

Implementing code formatting tools like ktfmt proved essential for maintaining a high-quality codebase. Implementing ktfmt improved code readability, reduced human errors, and facilitated better collaboration among team members. While there may be some initial challenges as to which formatting tool to use, how to set up and configure the plugin and the pre-commit hook, the long-term benefits far outweigh them.

Stay tuned for the next article, where we will delve into enhancing code quality with Detekt for static analysis. In the meantime check out our Barrage blog for more interesting topics.