1+ # Overview
2+
13This repository is a Racket package called Resyntax, which is a refactoring and
24static analysis tool for Racket code. It analyzes code using "refactoring
35rules" written in a domain-specific sublanguage of Racket and implemented using
46Racket's macro system. Resyntax then uses these rules to suggest ways people
57can improve their Racket code. See the [ Resyntax documentation] [ 1 ] and
68[ Racket website] [ 2 ] for more information.
79
10+ ## Adding New Refactoring Rules
11+
812When trying to add a new refactoring rule to Resyntax's default
913recommendations, pay special attention to the sections in the Resyntax
1014documentation on [ what makes a good refactoring rule] [ 3 ] and on
@@ -16,16 +20,43 @@ how to run it. Beware that Resyntax is *not* a `raco` command. Run it
1620using ` resyntax fix ` or ` resyntax analyze ` , not ` raco resyntax fix ` or
1721` raco resyntax analyze ` .
1822
19- When creating a pull request, avoid being overly verbose in the pull
20- request description. Keep descriptions to a single paragraph. If you need to
21- include example code, limit it to one or two small blocks. Do not write
22- lengthy, detailed explanations or documentation in the PR description.
23-
2423If you want to experiment with new refactoring rules you've created, consider
2524doing so by cloning the [ DrRacket] [ 6 ] , [ Herbie] [ 7 ] , or [ Typed Racket] [ 8 ]
2625repositories and running Resyntax on them. These repositories contain a lot
2726of Racket code and are good candidates for testing new refactoring rules.
2827
28+ ## Pull Request Style Conventions
29+
30+ When creating a pull request, avoid being overly verbose in the pull
31+ request description. Keep descriptions to a single paragraph. If you need to
32+ include example code, limit it to one or two small blocks. Do not write
33+ lengthy, detailed explanations or documentation in the PR description. Avoid
34+ mentioning things that are obvious from the code changes themselves, such as
35+ lists of files changed. Reserve the PR description for only the most essential
36+ information, and err on the side of omission. There is nothing wrong with a
37+ pull request description that is just a single sentence and a mention of what
38+ issue number is being addressed.
39+
40+ ## Code Coverage
41+
42+ When writing tests, you can use the [ ` raco cover ` ] [ 9 ] command to check the
43+ code coverage of your test cases. The command ` raco cover path/to/file.rkt `
44+ will generate an HTML report showing what code is covered by running the
45+ indicated files. To check coverage for the whole repository, you can run
46+ this command:
47+
48+ ``` bash
49+ raco cover --suppress-log-execution --package resyntax
50+ ```
51+
52+ The ` --suppress-log-execution ` flag is necessary to avoid a bug in ` raco cover `
53+ related to Racket's logging system. The ` raco cover ` tool has a few other sharp
54+ edges like this; see its documentation for more details.
55+
56+ Pull requests should aim for high code coverage, and an integration with Coveralls
57+ is set up to help track coverage over time. You can view the Coveralls report for
58+ the entire repository at [ this link] [ 10 ] .
59+
2960[ 1 ] : https://docs.racket-lang.org/resyntax/
3061[ 2 ] : https://racket-lang.org/
3162[ 3 ] : https://docs.racket-lang.org/resyntax/Refactoring_Rules_and_Suites.html#%28part._.What_.Makes_a_.Good_.Refactoring_.Rule_%29
@@ -34,3 +65,5 @@ of Racket code and are good candidates for testing new refactoring rules.
3465[ 6 ] : https://github.com/racket/drracket
3566[ 7 ] : https://github.com/herbie-fp/herbie
3667[ 8 ] : https://github.com/racket/typed-racket
68+ [ 9 ] : https://docs.racket-lang.org/cover/
69+ [ 10 ] : https://coveralls.io/github/jackfirth/resyntax
0 commit comments