How Google Takes The Pain Out Of Code Reviews, With 97% Dev Satisfaction
tl;dr: The author discusses: (1) Google’s guidelines for efficient code review. (2) Critique, Google’s code review tooling, and AI-powered improvements. (3) Internal statistics on Google code reviews. (4) Why Critique seems to be so loved by Googlers. Google’s guidelines for a good code review include: continuous improvement over perfection, maintain or improve the health of the codebase, and more.featured in #471
Common Authentication Implementation Risks And How To Mitigate Them
- James Hickey tl;dr: Data breaches are more common than ever. Ensuring a secure authentication system is critical to your trust with customers. Whether you build or buy your auth solution, this article offers insights into secure practices that can help keep you and your customers safe.featured in #467
Before You Try To Do Something, Make Sure You Can Do Nothing
- Raymond Chen tl;dr: "Too often, I see relatively inexperienced developers dive in and start writing a big complex thing: Then they can’t even get it to compile because it’s so big and complex. They ask for help, saying, “I’m having trouble with this one line of code,” but as you study what they have written, you realize that this one line of code is hardly the problem. The program hasn’t even gotten to the point where it can comprehend the possibility of executing that line of code. I mutter to myself, “How did you let it get this bad?”" Raymond gives the steps he takes to build a component.featured in #467
Tests Too DRY? Make Them DAMP!
- Derek Snyder Erik Kuefler tl;dr: The authors discuss the balance between the DRY (Don't Repeat Yourself) and DAMP (Descriptive and Meaningful Phrases) principles in unit testing. While DRY promotes code reuse and minimizes duplication, it may not always suit unit tests, as it can make them less readable and harder to manually inspect for correctness. The authors argue for prioritizing DAMP in tests to enhance readability, even if it leads to some code redundancy. They illustrate this with an example where creating users and assertions directly in the test, rather than using helper methods or loops, makes the test clearer. They acknowledge the relevance of DRY in tests for certain aspects but suggest leaning towards DAMP for better clarity and understanding in unit tests.featured in #464
Write Clean Code To Reduce Cognitive Load
- Andrew Trenk tl;dr: Cognitive load is often higher for other people reading code you wrote than it is for yourself. The key to reducing cognitive load is to make code simpler so it can be understood more easily by readers. Andrew elaborates on the following: (1) Limit the amount of code in a function or file. (2) Create abstractions to hide implementation details. (3) Simplify control flow. (4) Minimize mutable state. (5) Include only relevant details in tests. (6) Don’t overuse mocks in tests.featured in #463
How To (And How Not To) Design REST APIs
- Jeff Schnitzer tl;dr: "In my career, I have consumed hundreds of REST APIs and produced dozens. Since I often see the same mistakes repeated in API design, I thought it might be nice to write down a set of best practices. And poke fun at a couple widely-used APIs. Much of this may be "duh", but there might be a few rules you haven't considered yet."featured in #462
Use Abstraction To Improve Function Readability
- Palak Bansal Mark Manley tl;dr: The team at Google compares two functions and highlights how one is easier to follow due to its consistent level of abstraction, providing a top-down narrative of the code’s logic. createPizza is a high-level function that delegates the preparing, baking, and boxing steps to lower-level specialized functions with intuitive names. Those functions, in turn, delegate to their own lower-level specialized functions (e.g., heatOven) until they reach a function that handles implementation details without needing to call other functions.featured in #460
Improve Readability With Positive Booleans
- Max Kanat-Alexander tl;dr: (1) Name your flags and variables in such a way that they represent the positive check you wish to make - the presence of something, something being enabled, something being true - rather than the negative check you wish to make - the absence of something, something being disabled, something being false. (2) If your conditional looks like “if not … else …” then reverse it to put the positive case first.featured in #458
Authorization’s Spookiest Problem: Data
tl;dr: Between the dynamic nature of your application’s data model and the amount of application data needed to make authorization decisions, it’s no wonder data management is authorization’s spookiest problem. Join Oso's virtual event on October 31 where we'll share our best practices for building scalable and effective authorization systems, with a focus on storing, accessing and modeling the data.featured in #458
Git Commit And Commit Message Best Practices
- Justin Joyce tl;dr: Justin shares best practices for git commits and commit messages. Commit best practices include: (1) Commit often: Save work at incremental steps. (2) Keep commits self-contained: Ensure each commit represents a distinct piece of work. (3) Keep commits small: Commit frequently to maintain smaller changes. For commit messages: (1) Keep messages short: Aim for a one-liner, ideally under 70 characters. (2) Be descriptive yet concise: Summarize the commit's essence succinctly. (3) Be specific: Clearly indicate the nature and location of the change.The author emphasizes clarity and specificity over strict adherence to tense or voice in messages.featured in #456