At LeanMind, we love improving the code of the projects we work on and also sharing those discoveries with others.

It is important to write sustainable code, because in this way, it is cheaper to add or remove functionality, and it will be appreciated by colleagues and my future self. On this occasion, I would like to talk about the number of parameters in a method. The signature of a method is one of the first things a developer observes to understand what it does. If a method receives too many parameters, it becomes harder to understand, maintain, and test, because it is difficult to remember the order of the parameters, if we add another parameter, all calls are affected, and the code loses expressiveness. As can be seen in the following example:

class ReportService {
    generateReport(title: string, author: string, startDate: Date, endDate: Date, includeSummary: boolean, format: 'pdf' | 'excel' | 'csv' | 'json'): void {
		// lógica para generar informes
    }
}

As Robert C. Martin rightly says in his book Clean Code, the best methods are those that have no parameters, he adds that a method with more than three parameters is suspicious.[01] We also have to keep in mind that the more parameters a method has, it is likely breaking the single responsibility principle[02]

One of the strategies we can use is to define collaborators that we can inject via constructor. A case we see quite frequently is dates. Many times what can be done is to define a DateTimeService and inject it into the constructor, as shown in the following example:

public class UserService
{
	private readonly DateTimeService dateTimeService;
	private readonly UserRepository userRepository;
	
	public UserService(DateTimeService dateTimeService, UserRepository userRepository)
	{
		this.dateTimeService = dateTimeService;
		this.userRepository = userRepository;
	}
	
	public void CreateUser(string email, string password)
	{
		var user = new User(
			email: email,
			password: password,
			dateTimeCreation: dateTimeService.UtcNow());
		userRepository.Save(user);
	}
}

Another strategy we can use is to apply Parameter Object as Martin Fowler very well explains in his legendary book Refactoring[03], that is, if we have no choice but to pass many parameters to the method, we can group them into a class, as shown in the following example: Methods with many parameters

function sendEmail(to: string, subject: string, body: string, isHtml: boolean) {
  // lógica para enviar el email
}

sendEmail("user@example.com", "Bienvenido", "<h1>Hola</h1>", true);

After applying the Parameter Object refactor

type EmailMessage = {
  to: string;
  subject: string;
  body: string;
  isHtml: boolean;
};

function sendEmail(message: EmailMessage) {
  // lógica para enviar el email
}

We can see in the following example that the method call is greatly simplified and much clearer

sendEmail({
  to: "user@example.com",
  subject: "Bienvenido",
  body: "<h1>Hola</h1>",
  isHtml: true
});

Conclusion

Reducing the number of parameters in a method is not just an aesthetic issue, but one of clarity, maintainability, and software quality. A method with fewer parameters is easier to understand, less prone to errors, and more flexible to future changes.

---

References: [01] Clean Code by Robert C. Martin, page 40 [02] Agile Principles, Patterns, and Practices in C# by Robert C. Martin, page 155 [03] Refactoring, improving existing code by Martin Fowler, page 238