docs cleanup

README.md

@@ -20,6 +20,11 @@ After that, you can run readable on any file or directory like this:
 
     $ npx readable
 
+### Exit code
+
+Returns 0 if no errors. Returns 2 if there are some rrors. Can return 2 if some
+exception happend during linting.
+
 ### Configuration
 
 After running `readable --init`, you'll have a `.readable.json` file in your directory. In it, you'll see some rules configured like this:
@@ -79,16 +84,3 @@ To update api docs:
     npm run docs
 
 
-## TODO
-
- - [x] works for PHP initially, but a next version could support more languages, such as JS (next version not in scope)
- - [x] can easily run on the commandline (eg npm run analyze)
- - [x] can be plugged into our CI (running the cli command returns either green or red code-state via exit status)
- - [x] written in javascript or typescript. This way we have to option to build this into a vs code plugin (vs code plugin itself not in scope). We are open to other suggestions on this point
- - [x] does NOT have to parse code into an AST for static code-like analysis. We want to focus on coding conventions that can be detected with simpler methods (eg regex or pattern matching, simple algorithms,..)
- - [x] should be easy to extend with a new rule (documentation with samples should be provided)
- - [x] should run fast for the given ruleset ( below 1 minute for 2000+ php files of 100-150 lines)
- - [x] rules should be configurable (turned on/off and add parameters) via a json config file
- - [x] in order to use the analyzer on a CI on an existing codebase, we need a whitelist approach. One rule might have 100 violations, but we still want to use that rule on the codebase for new code. That means those 100 existing violations should be ignored. An ignore-config-file (similar to 'Psalm' by vimeo) should be used. A command should exist to generate such an ignore file. The ignore file should be json-structured. It should contain the types of violations, the filename/path and the amount of occurrences to be ignored in that file or folder.
- - [x] every rule should have at least a 2 unit tests, a green example and an example that is in violation
-

docs/rules.md

@@ -138,24 +138,3 @@ Avoid indent deeper than 4 (maximum block nesting, eg for loop within an if with
 ```JSON
 "max-nest": 3,
 ```
-
-## TODO
-
-Below is an exhaustive set of the initial rules we need implemented. Each rule should have it's own 'class/module' and act as a plugin for the wider system:
-
-- [x] avoid triple inner for/foreach (eg for within for within for loop)
-- [x] avoid a class without a single comment at the top stating purpose
-- [x] avoid any function longer than 50 lines
-- [x] avoid indent deeper than 4 (maximum block nesting, eg for loop within an if within a for loop within a for loop)
-- [x] avoid complicated ifs (eg more than 2 &&.., combination of && and ||)
-- [x] avoid ternary operator combined with line length exceeding 50 chars
-- [x] avoid namespaces with 15+ files
-- [x] avoid loops with inside of them more than 15 lines (a block that should be a function)
-- [x] avoid files with more than 200 lines.
-- [x] avoid dangerous calls to eval, print_r, var_export, var_dump, phpinfo, exec,..(forbidden function list)
-- [x] avoid assignment inside of an if statement
-- [x] avoid an if statement or for loop without braces
-- [x] avoid variables with names shorter than 3 letters (while whitelisting $i or $id)
-- [x]
-- [x] avoid overriding of a function's arguments
-- [x] avoid empty catch blocks