Deliver Software Security, Reliability, And Maintainability Through Clean Code Practices
- Gabriel Vivas tl;dr: Every company is a software company, and improving the quality, reliability, and security of your code matters. Sonar has spent the last 15 years building tools like SonarQube and SonarLint to help improve developer velocity, reduce code- level technical debt, and put security in the hands of developers. In this article, we detail how companies can make Clean Code a priority.featured in #474
featured in #473
How To Successfully Adopt A Developer Tool
- Lou Bichard tl;dr: Adopting developer tools is not the same as successfully adopting developers tools. It’s a socio-technical challenge involving strategy, timing and people that can be broken down into three steps: champions, use cases, scale. Avoid the premature ‘all-hands’ demo and embrace the power of building a champion.featured in #472
featured in #471
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