anchor.diff:  
   In IntelliJ IDEA, you must link:https://www.jetbrains.com/help/idea/gradle.html#gradle_import[import your project from the Gradle model] to get content-assist and refactoring tools for Kotlin DSL scripts.
   
  -In addition, IntelliJ IDEA or Android Studio might spawns up to 3 Gradle daemons when editing scripts; one per each type of script: project scripts, settings scripts and initialization scripts.
  +In addition, IntelliJ IDEA and Android Studio might spawn up to 3 Gradle daemons when editing scripts; one per each type of script: project scripts, settings scripts and initialization scripts.
   Builds with slow configuration time might affect the IDE responsiveness, please check out the link:https://guides.gradle.org/performance/#configuration[performance guide].
   
   === Automatic build import vs. automatic reload of script dependencies
  
positive.code: --
  
  Note that accessors for elements of containers such as `configurations`, `tasks` or `sourceSets` leverage Gradle's configuration avoidance APIs.
  For example on `tasks` they are of type `TaskProvider<T>` and provide a lazy reference and lazy configuration of the underlying task.
  
  [source,kotlin]
  ----
  
negative.code: === Via Kotlin delegated properties
  
  Another way to interact with containers is via Kotlin delegated properties that are particularly useful if you need a reference to a container element for further usage.
  By not using string literals for the element names, Kotlin delegated properties allow for easy renaming via IDE refactorings.
  The sample below does the exact same things as the one in the section above, reusing references to tasks instead of using task paths in string literals:
  
  .Via Kotlin delegated properties
  