# clean-code Clean coding is a set of principles and practices for producing readable, trusted, and maintainable code. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How a Tech Lead Encouraged Testing in Legacy Code DevFeed: [How a Tech Lead Encouraged Testing in Legacy Code]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-08-04T06:02:15Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [Test-driven development](), [legacy](), [clean-code](), [Template](), [Software Engineering]() Tags: [clean-code](), [legacy-code](), [tdd](), [tech-lead](), [training](), [unit-tests]() ### AI overview This opinion article recounts how an engineering leader struggled to introduce testing and clean-code practices across multiple companies. As a Tech Lead, the author created a testable Clean Architecture template, recruited developers who valued quality, built an initial module, and trained the team to use the approach. ### Source excerpt "We don't have time to write the code twice." ## 100 Tips to Write Clean Code DevFeed: [100 Tips to Write Clean Code]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-09-17T05:03:43Z Content type: article Language: en Sources: [Craft Better Software]() Topics: [clean-code](), [Programming](), [Development]() Tags: [clean-code](), [code](), [code-analysis](), [code-review](), [tips]() ### AI overview This article presents 100 practical tips for writing clean code that remains readable, testable, and maintainable. The covered guidance includes naming, functions, classes, comments, and commits, with recommendations such as using intention-revealing names, keeping functions concise, limiting class responsibilities, and avoiding side effects. ### Source excerpt Clean Functions, Classes, Comments, Commits and everything you need to write Clean Code ## Writing Clear, Focused Assertions in Unit Tests DevFeed: [Writing Clear, Focused Assertions in Unit Tests]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-05-24T05:01:11Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [Testing](), [Unit testing](), [clean-code]() Tags: [best-practices](), [clean-code](), [readability](), [techniques](), [testing](), [unit-testing](), [writing]() ### AI overview The article presents five practices for writing clean, expressive assertions in unit tests. It emphasizes testing one logical behavior per test, capturing domain knowledge through well-named helper functions, and treating tests as documentation. ### Source excerpt Best practices to nail the most important part of your unit test ## CodeRabbit as an AI Code Reviewer for Code Quality and Testing DevFeed: [CodeRabbit as an AI Code Reviewer for Code Quality and Testing]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-05-17T05:00:44Z Content type: opinion Language: en Sources: [Craft Better Software]() Topics: [Artificial Intelligence](), [Code review](), [Code quality](), [clean-code](), [Testing](), [Code](), [Security](), [SQL]() Tags: [ai](), [best-practices](), [code](), [code-quality](), [code-review](), [security](), [sql](), [testing]() ### AI overview The article presents CodeRabbit as an AI code reviewer that analyzes pull requests, summarizes changes, generates sequence diagrams, identifies security issues such as SQL injection risks, and suggests improvements to code quality and test coverage. ### Source excerpt How AI became my favorite code review partner ## Why the author questions SOLID and proposes CLARITY principles DevFeed: [Why the author questions SOLID and proposes CLARITY principles]() Original publisher: [Read original article]() Published: 2025-05-05T00:00:00Z Content type: opinion Language: en Sources: [Vasya Drobushkov]() Topics: [Development](), [Programming](), [clean-code]() Tags: [best-practices](), [development](), [opinions](), [programming]() ### AI overview The author argues that SOLID principles are interpreted inconsistently and that rigid application can produce difficult-to-maintain code. The article proposes using a set of principles called CLARITY instead, beginning with consistent abstraction levels. ### Source excerpt A long time ago, when I had just started my journey into programming, development, and engineering, it wasn't easy to find information, and bikeshedding could happen quite often because of that. We read books to gain insights into best practices and learn how to do things correctly. The concepts from the past were usually crucial and provided a great ramp-up to avoid obvious mistakes. Over time, we became flooded with information and opinions. In such an environment, old-time thoughts may even seem better, as they've been tested by time and by many engineers in the field. ## Six Principles for Writing Clean, Maintainable Classes DevFeed: [Six Principles for Writing Clean, Maintainable Classes]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-04-19T05:00:55Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [clean-code](), [Code](), [Development](), [implementation](), [Inheritance]() Tags: [classes](), [clean-code](), [code](), [implementation](), [inheritance](), [quality](), [reuse]() ### AI overview This tutorial presents six principles for writing clean classes: use noun-based names, avoid unnecessary getters and setters, hide internal state, expose a focused API, order methods by call flow, and favor composition over inheritance. It argues that small, focused, intention-revealing classes are easier to change, test, and understand. ### Source excerpt 7 essential tips to produce maintainable and intention-revealing classes ## 6 Testing Mistakes You Should Avoid DevFeed: [6 Testing Mistakes You Should Avoid]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-04-05T05:00:42Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [Testing](), [mutation-testing](), [Development](), [clean-code]() Tags: [apis](), [clean-code](), [code-testing](), [mutation-testing](), [shift-left](), [solid-principles](), [testing]() ### AI overview A practical guide to avoiding common testing mistakes, including testing late, relying too heavily on code coverage, testing implementation details, and neglecting clean test code. It recommends shift-left testing, mutation testing, behavior-focused tests through public APIs, and treating tests as maintainable code. ### Source excerpt Each with a simple fix you can apply today ## Clean Code Discussion DevFeed: [Clean Code Discussion]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-03-06T15:10:02Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [clean-code](), [Test-driven development](), [Testing](), [Refactoring](), [Code quality](), [Tooling](), [legacy]() Tags: [clean-code](), [code-quality](), [legacy](), [refactoring](), [tdd](), [testing](), [tooling]() ### AI overview A recording of a live discussion about Clean Code and Test-Driven Development. The speakers examine testing challenges, test smells, refactoring, tooling, code-quality practices, TDD adoption, team practices, event modeling, and legacy systems. ### Source excerpt A recording from Denis Čahuk's live video ## Test-driven Development, Clean Code, Teamwork DevFeed: [Test-driven Development, Clean Code, Teamwork]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-02-12T10:42:59Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [clean-code](), [Development]() Tags: [clean-code](), [development](), [tdd](), [teamwork]() ### AI overview A recorded live video discusses test-driven development, clean code, and teamwork conflicts, including practical TDD adoption, cultural shifts, incremental quality improvements, prioritization, resistance, and sustainable change. ### Source excerpt A recording from Denis Čahuk's live video ## There's No Such Thing as Clean Code DevFeed: [There's No Such Thing as Clean Code]() Original publisher: [Read original article]() Author: Steve Barnegren Published: 2022-01-27T00:00:00Z Content type: opinion Language: en Sources: [Steve Barnegren]() Topics: [clean-code](), [Code](), [Testing](), [interfaces]() Tags: [blog](), [blog-post](), [clean-code](), [code](), [developers](), [engineering](), [interfaces](), [technical](), [testing]() ### AI overview This opinion argues that "clean code" is not a useful technical measure because code quality involves different goals that can conflict. It recommends discussing concrete trade-offs and explaining why one solution is better or worse instead of treating "cleanest" as an objective metric. ### Source excerpt Everyone seems to be striving for 'clean' code at the moment. You can't read a blog post without the author telling you how clean their approach is. Engineering teams get together and discuss which of the possible solutions is the cleanest. Other developers assure you that they practice 'clean code'. ## Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem DevFeed: [Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem]() Original publisher: [Read original article]() Author: Danny Preussler Published: 2020-06-22T17:39:16Z Content type: opinion Language: en Sources: [Stories by Danny Preussler on Medium]() Topics: [Code](), [clean-code](), [Dagger](), [koin]() Tags: [android](), [clean-code](), [code](), [code-smells](), [constructor](), [dagger](), [dependencies](), [dependency-injection](), [koin](), [kotlin]() ### AI overview The article argues that dependency-injection tools can hide overly large constructors. It presents large constructors as a code smell that may indicate a violation of the Single Responsibility Principle, and notes that they make classes harder to test. ### Source excerpt How tools made us forget how to write sane constructors https://unsplash.com/photos/qvBYnMuNJ9A In an ideal world, developers get smarter every day. The code we write this year should be better than the code we wrote 10 years ago, which in turn should be better than the code 20 years ago. Today we have better tools, more modern languages, and better practices. But as often in life, we realize we are not living in that ideal world. In nearly every codebase I see today, there are things that would shock a developer two decades ago. I am speaking of what Mark Seemann called "Constructor Over Injection". We've all learned to inject our dependencies into constructors. And ideally use a tool for that like Spring or Dagger. If you look at some random classes from your codebase, how many fields are you injecting? Three? Five? More? I'm pretty sure you easily can find classes with even more, like this one: class ProfilePresenter @Inject constructor( @MainThreadScheduler private val mainScheduler: Scheduler, @IOScheduler private val ioScheduler: Scheduler, private val profileApi: ProfileApi, private val userRepository: UserRepository, private val analytics: Analytics, private val errorReporter: ErrorReporter private val referrerTracker: ReferrerTracker, private val shareTracker: ShareTracker, private val tracksRepository: TracksRepository, private val playlistRepository: PlaylistRepository ) If you would show this constructor to a developer from 20 years ago they would probably look at you as if you would be crazy. No one would want to call this constructor and provide all these parameters. But these days we don't care. We don't have to. We have a tool that will provide us with all those parameters, right? This does not make it right though! The proof If you would use some manual injection code or a service locator like Koin, you would notice more what's going on because you would need to write code like this: ProfilePresenter(get(), get(), get(), get(), get(), get(), get(), ## Goodbye, Clean Code DevFeed: [Goodbye, Clean Code]() Original publisher: [Read original article]() Published: 2020-01-11T00:00:00Z Content type: opinion Language: en Sources: [Dan Abramov]() Topics: [clean-code](), [Refactoring](), [Code](), [Graphics]() Tags: [clean-code](), [code](), [graphics](), [refactoring]() ### AI overview The author recounts refactoring repetitive shape-resizing code in a graphics editor and initially believing that eliminating duplication made the code better. Years later, they conclude that obsessing over measurable aspects of "clean code" can become a phase and that clean-code practices should guide development without becoming an end in themselves. ### Source excerpt Let clean code guide you. Then let it go. ## triversity - An Interview with two trivago Tech Camp Participants DevFeed: [triversity - An Interview with two trivago Tech Camp Participants]() Original publisher: [Read original article]() Author: Matthias Endler Published: 2019-10-23T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Software Engineering](), [Agile](), [web applications](), [Requirements](), [Deployment](), [Code review](), [clean-code]() Tags: [agile](), [clean-code](), [code-review](), [deployment](), [design](), [development](), [engineering-culture](), [frontend](), [interview](), [projects](), [prototype](), [requirements](), [web]() ### AI overview An interview with Gyumin Lee and Eunae Jang about their participation in trivago Tech Camp 2019. They describe developing triversity, a prototype project management web application for university collaboration, and learning software engineering practices through mentoring and an agile workflow. ### Source excerpt We are originally from South Korea and we've been in Germany for about three years.We often check the Facebook and Instagram posts from Life at trivago, so we could easily find out ab... ## Avoiding Dangerous IF Statements with Objects DevFeed: [Avoiding Dangerous IF Statements with Objects]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2016-06-24T00:00:00Z Content type: opinion Language: en Sources: [The Coffee Workshop]() Topics: [Code](), [clean-code](), [Architecture & Design](), [Software Engineering]() Tags: [clean-code](), [code](), [design](), [effective](), [software](), [software-design]() ### AI overview The Anti-IF Campaign advocates reducing problematic conditional statements by using objects and software design principles to make code more flexible, maintainable, and testable. ### Source excerpt A few book to posess Database Internals: A Deep Dive into How Distributed Data Systems Work by Alex Petrov BPF Performance Tools by Brendan Gregg Growing Object Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Reactive Design Patterns by Dr. Roland Kuhn, Brian Hanafee and Jamie Allen 97 Things Every Programmer Should Know Collective Wisdom Effective Java (3nd Edition) by Joshua Bloch Java Performance by Charlie Hunt Seven Concurrency Models in Seven Weeks: When Threads Unravel by Paul Butcher Clean Code by Rober C. Martin Domain Driven Design by Eric Evans Java Concurrency in Practice by Brian Goetz Real World Java EE Patterns by Adam Bien Pragmatic Thinking & Learning by Andy Hunt Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf Java EE 6 by Antonio Goncalves Patterns of Enterprise Application Architecture by Martin Fowler Business Model Generation by Alexander Osterwalter and Yves Pigneur Design Patterns by John Vlissides, Richard Helm, Ralph Johnson and Erich Gamma ## Flag-oriented Programming DevFeed: [Flag-oriented Programming]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2016-02-10T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Programming](), [clean-code](), [functions](), [Refactoring]() Tags: [clean-code](), [code](), [feature](), [programming]() ### AI overview The article argues that adding boolean flags to methods leads to flag-oriented programming: code becomes harder to understand, maintain, maintain, extend, and test as features accumulate. It presents decorators as a more readable and composable alternative. ### Source excerpt booleans, am I right? What a wonderful piece of technology! They help us solve so many problems... ## What is good code? DevFeed: [What is good code?]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2015-12-27T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Code](), [Refactoring](), [clean-code](), [Programming](), [functions](), [unit tests](), [classes](), [object]() Tags: [classes](), [clean-code](), [code](), [functions](), [object](), [refactoring](), [unit-tests]() ### AI overview A personal essay reevaluates common ideas about good code, including small methods and classes, meaningful names, unit tests, and refactoring. The author reflects on how experience and studying object-oriented programming changed their view of Clean Code guidance. ### Source excerpt I've been wanting to write this for a long time, just to clarify my thoughts on the subject. Now, on vacations, I took a couple of days and finally did it. This is a personal opinion based on my personal experience and tons of books I have read, and I am not, by any means, the supreme holder of the truth, so you will probably disagree with me at some point. ## Stop Copying Social Code Snippets DevFeed: [Stop Copying Social Code Snippets]() Original publisher: [Read original article]() Published: 2014-04-20T23:17:32Z Content type: opinion Language: en Sources: [Philip Walton]() Topics: [Web Development](), [clean-code](), [Code](), [JavaScript](), [browsers]() Tags: [browsers](), [clean-code](), [code](), [developer](), [javascript](), [web]() ### AI overview The article argues that professional web developers should avoid blindly copying prepackaged social widget code snippets. It recommends understanding and, where appropriate, improving the code to reduce unnecessary complexity and support performance, reusability, and clean code. ### Source excerpt If you're a web developer, chances are, at some point, you've had to add a social widget to one of your page. Actually, probably more than one. And chances are you didn't want to put too much thought into it, so you just copied some code from the Internet and called it a day. Done and done. ## The Great Leap - getting serious with JavaScript at FINN.no DevFeed: [The Great Leap - getting serious with JavaScript at FINN.no]() Original publisher: [Read original article]() Author: espen Published: 2011-04-01T11:45:39Z Content type: article Language: en Sources: [Finn.no]() Topics: [JavaScript](), [Test-driven development](), [Testing](), [clean-code](), [HTML](), [Java]() Tags: [clean-code](), [code](), [html](), [java](), [javascript](), [legacy](), [refactor](), [testing]() ### AI overview FINN.no describes a live coding session focused on testing JavaScript with Test-Driven Development. The examples include designing a type-ahead HTML widget and testing legacy JavaScript used in the platform's advanced search. The article also identifies a validation bug involving JavaScript's bitwise AND operator. ### Source excerpt FINN.no are blessed to be based in the same country as one of the brightest young stars when it comes to testing in JavaScript and applying Test Driven Development: Christian Johansen (the poster above was used to promote the event). He works as a developer at Gitorious during the day time, but he also cranks out frameworks like SinonJS and he has even published a book on how to do Test Driven Development in JavaScript. Driving your design with tests We first had an amazing live coding session which he had previously done at FrontTrends. The task was to create a type-ahead widget which sent requests to a server if the delay was more than 50 millies. Driving the design of an HTML widget with tests is just as awesome as doing the same thing with JUint on the back-end. You get a nice set of really simple objects which provide you with a set of tools to create the functionality you want. This is very different from the one-object-with-everything kind of code you see a lot of when you do not focus upon design before you code. You can accomplish good clean code without Refactor some legacy code with tests We have just recently ported parts of our platform related to advanced search to a new Java framework, but we did not port much of the JavaScript code. Only thing we have done is to prevent it from flooding the global scope and extract the JS code into a separate file. Christian gave us the challenge of trying to test this code. This was by no means an easy task. The code was not written with testing in mind. It has some weird coding errors which for some reason does not produce errors in the user interface. Stuff like a function which one would expect to return a boolean, but when we tried to assertTrue on the result of a validation it failed and we couldn't see why. function validateForm() { var valid = true; $("input.number").each(function(){ valid &= validateInput($(this)); }); return valid; } ... if (validateForm()) { ....} That was until we noticed the bitwise and