anchor.diff:  </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.
  +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">
  
positive.code: 
  ==== Alternatives for oft-used internal APIs
  
  To provide a nested DSL for your custom task, don't use `org.gradle.internal.reflect.Instantiator`; use api:org.gradle.api.model.ObjectFactory[] instead. It may also be helpful to read <<lazy_configuration>>.
  
  Don't use `org.gradle.api.internal.ConventionMapping`. Use api:org.gradle.api.provider.Provider[] and/or api:org.gradle.api.provider.Property[]. You can find an example for capturing user input to configure runtime behavior in the link:https://guides.gradle.org/implementing-gradle-plugins/#capturing_user_input_to_configure_plugin_runtime_behavior[implementing plugins guide].
  
  Instead of `org.gradle.internal.os.OperatingSystem`, use another method to detect operating system, such as link:https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/SystemUtils.html[Apache commons-lang SystemUtils] or `System.getProperty("os.name")`.
  
  
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">
  