diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/dev/style.md | 33 | ||||
-rw-r--r-- | docs/user/manual.adoc | 35 |
2 files changed, 68 insertions, 0 deletions
diff --git a/docs/dev/style.md b/docs/dev/style.md index 6ab60b50e..00de7a711 100644 --- a/docs/dev/style.md +++ b/docs/dev/style.md | |||
@@ -449,6 +449,39 @@ fn query_all(name: String, case_sensitive: bool) -> Vec<Item> { ... } | |||
449 | fn query_first(name: String, case_sensitive: bool) -> Option<Item> { ... } | 449 | fn query_first(name: String, case_sensitive: bool) -> Option<Item> { ... } |
450 | ``` | 450 | ``` |
451 | 451 | ||
452 | ## Prefer Separate Functions Over Parameters | ||
453 | |||
454 | If a function has a `bool` or an `Option` parameter, and it is always called with `true`, `false`, `Some` and `None` literals, split the function in two. | ||
455 | |||
456 | ```rust | ||
457 | // GOOD | ||
458 | fn caller_a() { | ||
459 | foo() | ||
460 | } | ||
461 | |||
462 | fn caller_b() { | ||
463 | foo_with_bar(Bar::new()) | ||
464 | } | ||
465 | |||
466 | fn foo() { ... } | ||
467 | fn foo_with_bar(bar: Bar) { ... } | ||
468 | |||
469 | // BAD | ||
470 | fn caller_a() { | ||
471 | foo(None) | ||
472 | } | ||
473 | |||
474 | fn caller_b() { | ||
475 | foo(Some(Bar::new())) | ||
476 | } | ||
477 | |||
478 | fn foo(bar: Option<Bar>) { ... } | ||
479 | ``` | ||
480 | |||
481 | **Rationale:** more often than not, such functions display "`false sharing`" -- they have additional `if` branching inside for two different cases. | ||
482 | Splitting the two different control flows into two functions simplifies each path, and remove cross-dependencies between the two paths. | ||
483 | If there's common code between `foo` and `foo_with_bar`, extract *that* into a common helper. | ||
484 | |||
452 | ## Avoid Monomorphization | 485 | ## Avoid Monomorphization |
453 | 486 | ||
454 | Avoid making a lot of code type parametric, *especially* on the boundaries between crates. | 487 | Avoid making a lot of code type parametric, *especially* on the boundaries between crates. |
diff --git a/docs/user/manual.adoc b/docs/user/manual.adoc index 54195adb7..58722aaa3 100644 --- a/docs/user/manual.adoc +++ b/docs/user/manual.adoc | |||
@@ -611,6 +611,41 @@ For example, mutable bindings are underlined by default and you can override thi | |||
611 | } | 611 | } |
612 | ---- | 612 | ---- |
613 | 613 | ||
614 | Most themes doesn't support styling unsafe operations differently yet. You can fix this by adding overrides for the rules `operator.unsafe`, `function.unsafe`, and `method.unsafe`: | ||
615 | |||
616 | [source,jsonc] | ||
617 | ---- | ||
618 | { | ||
619 | "editor.semanticTokenColorCustomizations": { | ||
620 | "rules": { | ||
621 | "operator.unsafe": "#ff6600", | ||
622 | "function.unsafe": "#ff6600" | ||
623 | "method.unsafe": "#ff6600" | ||
624 | } | ||
625 | }, | ||
626 | } | ||
627 | ---- | ||
628 | |||
629 | In addition to the top-level rules you can specify overrides for specific themes. For example, if you wanted to use a darker text color on a specific light theme, you might write: | ||
630 | |||
631 | [source,jsonc] | ||
632 | ---- | ||
633 | { | ||
634 | "editor.semanticTokenColorCustomizations": { | ||
635 | "rules": { | ||
636 | "operator.unsafe": "#ff6600" | ||
637 | }, | ||
638 | "[Ayu Light]": { | ||
639 | "rules": { | ||
640 | "operator.unsafe": "#572300" | ||
641 | } | ||
642 | } | ||
643 | }, | ||
644 | } | ||
645 | ---- | ||
646 | |||
647 | Make sure you include the brackets around the theme name. For example, use `"[Ayu Light]"` to customize the theme Ayu Light. | ||
648 | |||
614 | ==== Special `when` clause context for keybindings. | 649 | ==== Special `when` clause context for keybindings. |
615 | You may use `inRustProject` context to configure keybindings for rust projects only. | 650 | You may use `inRustProject` context to configure keybindings for rust projects only. |
616 | For example: | 651 | For example: |