anchor.diff:  [[sec:minimize_logic_executed_configuration_phase]]
   === Minimize logic executed during the configuration phase
   
  -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.
  -
  -Let's consider the following incantation of the anti-pattern described above. In the build script you can see that the dependencies assigned to the configuration `printArtifactNames` are resolved outside of the task action.
  +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.
  +
  +Let's consider the following incantation of the anti-pattern described above.
  +In the build script you can see that the dependencies assigned to the configuration `printArtifactNames` are resolved outside of the task action.
   
   ++++
   <sample id="logicDuringConfigurationPhase" dir="userguide/bestPractices/logicDuringConfiguration/dont" title="Executing logic during configuration should be avoided">
  
positive.code: </sample>
  ++++
  
  Let's compare the build script with the same logic implemented as a binary plugin. The code might look more involved at first but clearly looks more like typical application code. This particular plugin class lives in the <<sec:build_sources,`buildSrc` directory>> which makes it available to the build script automatically.
  
  ++++
  <sample id="conditionalLogicDo" dir="userguide/bestPractices/conditionalLogic/do/buildSrc/src/main/java/com/enterprise" title="A binary plugin implementing imperative logic">
  
negative.code: [[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.
  
  The example task `generateDocs` generates documentation for a project in the form of HTML pages.
  The task should be organized underneath the bucket `Documentation`.
  The description should express its intent.
  
  ++++
  <sample id="taskGroupDescription" dir="userguide/bestPractices/taskGroupDescription" title="A task declaring the group and description">
  