anchor.diff:  The third-party link:https://github.com/nebula-plugins/gradle-lint-plugin[Gradle lint plugin] helps with enforcing a desired code style in a build script if you are looking for appropriate linting automation.
   ====
   
  -[[sec:declare_task_group_and_description]]
  -=== Declare the group and description for tasks
  +[[sec:improving_task_discoverability]]
  +=== Improving task discoverability
   
   Even new users to a build should to be able to find crucial information quickly and effortlessly. In Gradle you can declare a api:org.gradle.api.Task#setGroup(java.lang.String)[group] and a api:org.gradle.api.Task#setDescription(java.lang.String)[description] for any task of the build. The <<sec:listing_tasks,tasks report>> uses the assigned values to organize and render the task for easy discoverability. Assigning a group and description is most helpful for any task that you expect build users to invoke.
   
  
positive.code: </sample>
  ++++
  
  [[sec:avoid_use_of_passwords_in_plain_text]]
  === Avoid the use of passwords in plain text
  
  Most builds need to consume one or many passwords. The reasons for this need may vary. Some builds need a password for publishing artifacts to a secured binary repository, other builds need a password for downloading binary files. Passwords should always kept safe to prevent fraud. Under no circumstance should you add the password to the build script as property in plain text or declare it in a `gradle.properties`. Those files usually live in a version control repository and can be viewed by anyone that has access to it.
  
  Passwords should be stored in encrypted fashion. At the moment Gradle does not provide a built-in mechanism for encrypting, storing and accessing passwords. A good solution for solving this problem is the link:https://github.com/etiennestuder/gradle-credentials-plugin[Gradle Credentials plugin].
  
  
  
negative.code: generateDocs - Generates the HTML documentation for this project.
  ----
  
  [[sec:avoiding_execution_actions_during_configuration]]
  === Avoiding execution actions during Gradle configuration
  
  It's important for every build script developer to understand the different phases of the <<build_lifecycle,build lifecycle>> and their implications on performance and evaluation order of build logic. During the configuration phase the project and its domain objects should be _configured_, whereas the execution phase only executes the actions of the task(s) requested on the command line plus their dependencies. Be aware that any code that is not part of a task action will be executed with _every single run_ of the build. A link:https://scans.gradle.com/get-started[build scan] can help you with identifying the time spent during each of the lifecycle phases. It's an invaluable tool for diagnosing common performance issues.
  
  