anchor.diff:  ++++
   
   [[sec:avoid_imperative_logic_in_scripts]]
  -=== Avoid imperative logic in scripts
  +=== Avoiding imperative logic in scripts
   
   The Gradle runtime does not enforce a specific style for build logic. For that very reason, it's easy to end up with a build script that mixes declarative DSL elements with imperative, procedural code. Let's talk about some concrete examples.
   
  
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.
  
  