1 files changed, 5 insertions, 2 deletions
diff --git a/docs/dev/README.md b/docs/dev/README.md
index 6b6824ded..f87462400 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -177,6 +177,9 @@ There are many benefits to this:
 * less stuff printed during printf-debugging
 * less time to run test
+It also makes sense to format snippets more compactly (for example, by placing enum defitions like `enum E { Foo, Bar }` on a single line),
+as long as they are still readable.
 ## Order of Imports
 We separate import groups with blank lines
@@ -358,10 +361,10 @@ There are two kinds of tests:
 The purpose of inline tests is not to achieve full coverage by test cases, but to explain to the reader of the code what each particular `if` and `match` is responsible for.
 If you are tempted to add a large inline test, it might be a good idea to leave only the simplest example in place, and move the test to a manual `parser/ok` test.
-To update test data, run with `UPDATE_EXPECTATIONS` variable:
+To update test data, run with `UPDATE_EXPECT` variable:
 ```bash
-env UPDATE_EXPECTATIONS=1 cargo qt
+env UPDATE_EXPECT=1 cargo qt
 ```
 After adding a new inline test you need to run `cargo xtest codegen` and also update the test data as described above.

diff --git a/docs/dev/README.md b/docs/dev/README.md index 6b6824ded..f87462400 100644 --- a/docs/dev/README.md +++ b/docs/dev/README.md
@@ -177,6 +177,9 @@ There are many benefits to this:
177	* less stuff printed during printf-debugging	177	* less stuff printed during printf-debugging
178	* less time to run test	178	* less time to run test
179		179
		180	It also makes sense to format snippets more compactly (for example, by placing enum defitions like `enum E { Foo, Bar }` on a single line),
		181	as long as they are still readable.
		182
180	## Order of Imports	183	## Order of Imports
181		184
182	We separate import groups with blank lines	185	We separate import groups with blank lines
@@ -358,10 +361,10 @@ There are two kinds of tests:
358	The purpose of inline tests is not to achieve full coverage by test cases, but to explain to the reader of the code what each particular `if` and `match` is responsible for.	361	The purpose of inline tests is not to achieve full coverage by test cases, but to explain to the reader of the code what each particular `if` and `match` is responsible for.
359	If you are tempted to add a large inline test, it might be a good idea to leave only the simplest example in place, and move the test to a manual `parser/ok` test.	362	If you are tempted to add a large inline test, it might be a good idea to leave only the simplest example in place, and move the test to a manual `parser/ok` test.
360		363
361	To update test data, run with `UPDATE_EXPECTATIONS` variable:	364	To update test data, run with `UPDATE_EXPECT` variable:
362		365
363	```bash	366	```bash
364	env UPDATE_EXPECTATIONS=1 cargo qt	367	env UPDATE_EXPECT=1 cargo qt
365	```	368	```
366		369
367	After adding a new inline test you need to run `cargo xtest codegen` and also update the test data as described above.	370	After adding a new inline test you need to run `cargo xtest codegen` and also update the test data as described above.