From 55155847cb6a5fd0d5b3ba5a971dce0ccc3c4eaa Mon Sep 17 00:00:00 2001 From: Bojun Chai Date: Tue, 21 Apr 2026 09:03:25 +0800 Subject: [PATCH] use 'cannot' (one word) in two prose passages --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index bd91faf2ea..eb5fef6798 100644 --- a/README.md +++ b/README.md @@ -887,7 +887,7 @@ Other Style Guides - [7.14](#functions--spread-vs-apply) Prefer the use of the spread syntax `...` to call variadic functions. eslint: [`prefer-spread`](https://eslint.org/docs/rules/prefer-spread) - > Why? It’s cleaner, you don’t need to supply a context, and you can not easily compose `new` with `apply`. + > Why? It’s cleaner, you don’t need to supply a context, and you cannot easily compose `new` with `apply`. ```javascript // bad @@ -3535,7 +3535,7 @@ Other Style Guides ``` - - [23.10](#naming--uppercase) You may optionally uppercase a constant only if it (1) is exported, (2) is a `const` (it can not be reassigned), and (3) the programmer can trust it (and its nested properties) to never change. + - [23.10](#naming--uppercase) You may optionally uppercase a constant only if it (1) is exported, (2) is a `const` (it cannot be reassigned), and (3) the programmer can trust it (and its nested properties) to never change. > Why? This is an additional tool to assist in situations where the programmer would be unsure if a variable might ever change. UPPERCASE_VARIABLES are letting the programmer know that they can trust the variable (and its properties) not to change. - What about all `const` variables? - This is unnecessary, so uppercasing should not be used for constants within a file. It should be used for exported constants however.