anchor.diff:  While this code snippet is small, it is easy to imagine a full-blown build script using numerous procedural statements and the impact it would have on readability and maintainability.
   By moving the code into a class link:{guidesUrl}/testing-gradle-plugins/[testability] also becomes a valid option.
   
  -=== Example: A build script using conditional logic to create a task
  -
  -[source.multi-language-sample,groovy]
  -.build.gradle
  -----
  -include::{samplesPath}/userguide/bestPractices/conditionalLogic/dont/build.gradle[]
  -----
  +.A build script using conditional logic to create a task
  +====
  +include::sample[dir="userguide/bestPractices/conditionalLogic/dont", files="build.gradle[]"]
  +====
   
   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 <<organizing_gradle_projects.adoc#sec:build_sources,`buildSrc` directory>> which makes it available to the build script automatically.
   
  -=== Example: A binary plugin implementing imperative logic
  -
  -[source,java]
  -.ReleasePlugin.java
  -----
  -include::{samplesPath}/userguide/bestPractices/conditionalLogic/do/buildSrc/src/main/java/com/enterprise/ReleasePlugin.java[]
  -----
  +.A binary plugin implementing imperative logic
  +====
  +include::sample[dir="userguide/bestPractices/conditionalLogic/do/buildSrc/src/main/java/com/enterprise", files="ReleasePlugin.java[]"]
  +====
   
   Now that the build logic has been translated into a plugin, you can apply it in the build script.
   The build script has been shrunk from 8 lines of code to a one liner.
   
  -=== Example: A build script applying a plugin that encapsulates imperative logic
  -
  -[source.multi-language-sample,groovy]
  -.build.gradle
  -----
  -include::{samplesPath}/userguide/bestPractices/conditionalLogic/do/build.gradle[]
  -----
  +.A build script applying a plugin that encapsulates imperative logic
  +====
  +include::sample[dir="userguide/bestPractices/conditionalLogic/do", files="build.gradle[]"]
  +====
   
   [[sec:avoiding_gradle_internal_apis]]
   == Avoiding Gradle internal APIs
  
positive.code: The task should be organized underneath the bucket `Documentation`.
  The description should express its intent.
  
  === Example: A task declaring the group and description
  
  [source.multi-language-sample,groovy]
  .build.gradle
  ----
  include::{samplesPath}/userguide/bestPractices/taskGroupDescription/build.gradle[]
  ----
  
  The output of the tasks report reflects the assigned values.
  
  
negative.code: 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.
  
  .Executing logic during configuration should be avoided
  ====
  include::sample[dir="userguide/bestPractices/logicDuringConfiguration/dont", files="build.gradle[tags=config-logic]"]
  ====
  
  The code for resolving the dependencies should be moved into the task action to avoid the performance impact of resolving the dependencies before they are actually needed.
  
  .Executing logic during execution phase is preferred
  ====
  include::sample[dir="userguide/bestPractices/logicDuringConfiguration/do", files="build.gradle[tags=config-logic]"]
  ====
  
  [[sec:avoiding_use_of_gradlebuild]]
  == Avoiding the use of `GradleBuild`
  