From 6d5a3bae39ca0b0c8c2817124da5a27eb295ab3e Mon Sep 17 00:00:00 2001 From: Sander Saares Date: Wed, 22 Oct 2025 08:05:44 +0300 Subject: [PATCH] COGS -> efficiency The term COGS (which was occasionally misspelled as COGs) feels like a potentially foreign term to the non-corporate part of the readership. This replaces it with "efficiency", which feels like the nearest Earthacan equivalent term. --- README.md | 2 +- src/guidelines/README.md | 4 ++-- src/guidelines/performance/M-HOTPATH.md | 2 +- src/guidelines/performance/M-THROUGHPUT.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 1581353..efd4009 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ mdbook serve --open To submit new guidelines, file a PR. They should be -- beneficial for { safety, COGs, maintenance }, +- beneficial for { safety, efficiency, maintenance }, - agreeable to a majority of experienced (3+ years) Rust developers, - comprehensible to Rust novices (4+ weeks), - practically applicable in real world scenarios. diff --git a/src/guidelines/README.md b/src/guidelines/README.md index 763538c..05fa236 100644 --- a/src/guidelines/README.md +++ b/src/guidelines/README.md @@ -9,7 +9,7 @@ A collection of pragmatic design guidelines helping application and library deve We build on existing high-quality guidelines, most notably the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/checklist.html), addressing topics often encountered by Rust developers. For a guideline to make it into this book, we expect it to meet the following criteria: -- [ ] It positively affects { safety, COGs, maintenance }; i.e., it must where applicable +- [ ] It positively affects { safety, efficiency, maintenance }; i.e., it must where applicable - [ ] promote **safety best-practices** and prevent sources of risk - [ ] lead to **high throughput**, **low latency**, and **low memory usage** - [ ] make code **readable and understandable** @@ -41,7 +41,7 @@ spirit. ## Submitting New Guidelines -Do you have a practical guideline that leads to better safety, COGS or maintainability? We'd love to hear from you! +Do you have a practical guideline that leads to better safety, efficiency or maintainability? We'd love to hear from you! Here is the process you should follow: - Check if your guideline follows the [meta design principles](#meta-design-principles) above. diff --git a/src/guidelines/performance/M-HOTPATH.md b/src/guidelines/performance/M-HOTPATH.md index e6b3550..8ea42c2 100644 --- a/src/guidelines/performance/M-HOTPATH.md +++ b/src/guidelines/performance/M-HOTPATH.md @@ -5,7 +5,7 @@ To end up with high performance code. 0.1 -You should, early in the development process, identify if your crate is performance or COGS relevant. If it is: +You should, early in the development process, identify if your crate is performance or efficiency relevant. If it is: - identify hot paths and create benchmarks around them, - regularly run a profiler collecting CPU and allocation insights, diff --git a/src/guidelines/performance/M-THROUGHPUT.md b/src/guidelines/performance/M-THROUGHPUT.md index 4d224c7..8a255d3 100644 --- a/src/guidelines/performance/M-THROUGHPUT.md +++ b/src/guidelines/performance/M-THROUGHPUT.md @@ -2,7 +2,7 @@ ## Optimize for Throughput, Avoid Empty Cycles (M-THROUGHPUT) { #M-THROUGHPUT } -To ensure COGS savings at scale. +To ensure efficiency at scale. 0.1 You should optimize your library for throughput, and one of your key metrics should be _items per CPU cycle_.