# Guiding principles for ick

Pithily,

* First, corrupt no source code.
* Second, don't reinvent what works.

## Explicit goals

* Always give the user an "undo" (default to an informative dry run)
* Be something that one person on a team can adopt, if they're the only one that cares
* Be something that you can run infrequently (say, before a release or in a tech
  debt week), while resepcting the amount of time you have available
* Don't be tied to any one {language,os,etc}: Be agnostic to what tools people
  want to use
* Give you a heads-up about recommendations that you don't need to apply yet
  (but can if you have spare time or want to be an early adopter)

By accomodating a wide range of levels of effort, we can apply automation where
it makes sense, especially on the low end of complexity.  If you haven't wanted
to write a custom linter plugin because it's hard, and resorted to a `grep`
somewhere, this framework is for you.


## Ease of adoption

Using `ick` (generally) doesn't require any in-repo configuration, doesn't
require all committers to use it, and doesn't require using any third-party
services.  You can try it, and if it's not useful for you, just don't run it again.