Things Not to Discuss in Reviews of .NET Code

Things NOT to Say in.NET Code Reviews will be covered in this post.

Now let’s begin.

A key component of excellent.NET engineering is code reviews. They are about sharing knowledge, upholding consistency, and enhancing teamwork, not just finding bugs.

But the manner in which feedback is given is just as important as the content.

Here are some popular terms that should be avoided in.NET code reviews, along with preferable substitutes that encourage technical brilliance, clarity, and respect.

1. “You should have used Strategy Pattern”

Better Alternative:

“What do you think about using the Strategy Pattern here to make this more extensible?”

2. “This code is a mess”

Better Alternative:

“I see some opportunities for simplification—maybe we can break this into smaller methods or services?”

3. “This code will crash; fix it”

Better Alternative:

“This might throw an exception in certain scenarios—should we improve error handling here?”

4. “You’re doing this completely wrong”

Better Alternative:

“Here’s an approach that might be more maintainable in the long run—what do you think?”

5. “Why didn’t you just do X?”

Better Alternative:

“Have you considered using an alternative approach, like async/await or LINQ here?”

6. “This is obviously inefficient”

Better Alternative:

“I noticed potential performance implications—maybe we can optimize this EF query or reduce allocations?”

7. “Only a junior would write this”

Better Alternative:

“There’s a pattern we often use in .NET for this scenario—should we apply it here?”

8. “Change this to use async/await”

Better Alternative:

“Since this involves I/O, could we refactor this to use async/await to avoid blocking threads?”

9. “This will cause bugs”

Better Alternative:

“We might prevent edge cases here by adding validation or null checks.”

10. “Never use global variables”

Better Alternative:

“Would dependency injection be a better fit here to improve testability and maintainability?”

11. “Where are the tests? Do you even care about quality?”

Better Alternative:

“Let’s make sure we have test coverage for this feature—especially for edge cases.”

12. “Your code is hard to understand”

Better Alternative:

“This section could benefit from clearer naming or a short comment explaining the intent.”

13. “What a mess. Nobody can review 2,000 lines”

Better Alternative:

“Would it be possible to split this into smaller PRs for easier review?”

14. “Why is this so complicated?”

Better Alternative:

“Could we simplify this or break it into smaller functions for better readability?”

15. “This function is stupid”

Better Alternative:

“Can we simplify this function to improve clarity and maintainability?”

16. “Change this name or I’m blocking the PR”

Better Alternative:

“Maybe we can improve this name for clarity—happy to approve and follow up if needed.”

17. “You’re not following standards”

Better Alternative:

“Let’s align this with our team’s coding standards—here’s a reference.”

18. “You changed behavior and forgot docs”

Better Alternative:

“Should we update the README or API documentation to reflect this change?”

19. “This PR has zero context. Am I supposed to guess?”

Better Alternative:

“Could you add a bit more context on the scope and risks in the PR description?”

20. “Your spacing is a disaster. Fix it before I look further”

Better Alternative:

“Let’s focus on the logic first—formatting can be tidied up afterward or auto-formatted.”

21. “This LINQ is wrong.”

Better Alternative:

“This LINQ query might evaluate multiple times—should we materialize it with .ToList() here?”

22. “Why didn’t you use async?”

Better Alternative:

“Since this calls I/O, could we make this async/await to avoid blocking threads?”

23. “Don’t use var.”

Better Alternative:

“Would explicitly typing this improve readability here, or is var still clear?”

24. “This controller is messy.”

Better Alternative:

“This controller has a bit of logic—should we move some of it into a service for better separation?”

25. “Bad EF usage.”

Better Alternative:

“This EF query might cause N+1 issues—should we add .Include() or rethink the projection?”

26. “You forgot null checks.”

Better Alternative:

“Should we guard against null here or use nullable reference types (?) for safety?”

27. “This will crash.”

Better Alternative:

“This could throw a NullReferenceException in a specific scenario—should we add a check or fallback?”

28. “Don’t hardcode values.”

Better Alternative:

“Maybe we could move this to appsettings.json or IOptions<T> for configurability?”

29. “Too much logic in Program.cs / Startup.”

Better Alternative:

“Would it help clarity if we extracted this into an extension method like AddCustomServices()?”

30. “This method is too big.”

Better Alternative:

“Could we break this into smaller methods to improve readability and testability?”

31. “Terrible naming.”

Better Alternative:

“Maybe we can rename this to better reflect its intent—something like CalculateInvoiceTotal?”

32. “You’re not following SOLID.”

Better Alternative:

“This class has multiple responsibilities—should we split it to align better with SRP?”

33. “Why no logging?”

Better Alternative:

“Should we add structured logging (for example, ILogger) here for observability?”

34. “This middleware is wrong.”

Better Alternative:

“This middleware might run in the wrong order—should it come before authentication?”

35. “This API is not RESTful.”

Better Alternative:

“Would this endpoint be clearer if we used a more conventional route like GET /orders/{id}?”

36. “Bad exception handling.”

Better Alternative:

“Instead of catching generic exceptions, should we handle specific ones or use a global exception middleware?”

37. “This test is useless.”

Better Alternative:

“Could we improve this test by asserting behavior instead of just calling the method?”

38. “No DI here?”

Better Alternative:

“Would injecting this dependency improve testability and align with our DI pattern?”

39. “Performance is bad.”

Better Alternative:

“This might allocate a lot of objects—should we consider Span<T> or caching here if it’s a hot path?”

40. “This is overkill.”

Better Alternative:

“Do we need this level of abstraction here, or could a simpler approach meet the requirement?”

Bonus: .NET-Specific Review Tone Patterns

Prefer Phrases Like

• “Should we consider…”
• “Would it help if…”
• “What do you think about using…”
• “Could this cause issues with…”

These phrases encourage discussion instead of creating defensiveness.

Why This Matters in .NET Teams

In modern .NET environments such as ASP.NET Core, EF Core, and microservices-based systems, collaboration is critical.

Poorly phrased feedback can:

• Create defensiveness.
• Slow down delivery.
• Reduce knowledge sharing.

Great reviews, on the other hand:

• Encourage better architecture decisions (DI, async, layering).
• Improve performance (EF queries, allocations).
• Strengthen code quality and maintainability.

A Better Review Pattern (Senior/Staff Level)

Use this simple structure:

Observation → Impact → Suggestion

This format keeps feedback objective, actionable, and easy to understand.

Example

“This EF query might trigger multiple database calls (observation), which could impact performance under load (impact). Maybe we can use .Include() or project to a DTO (suggestion).”

Elevate Reviews with .NET Architecture Principles

When providing feedback, connect suggestions to established .NET practices such as:

• Dependency Injection
• Clean Architecture
• Async best practices
• EF Core performance patterns
• Observability (logging and tracing)

This helps reviewers explain not just what should change, but why it matters.

Benefits of Constructive Code Reviews

Constructive reviews help teams:

• Build trust.
• Improve communication.
• Share knowledge effectively.
• Maintain coding standards.
• Increase development velocity.
• Reduce technical debt.
• Create a stronger engineering culture.

Key Takeaway

The goal of a code review is not to prove someone wrong. The goal is to improve the code, share knowledge, and help the team make better technical decisions together. Small changes in wording can transform a review from a frustrating experience into a valuable learning opportunity.

Final Thoughts

A great .NET code review is not about proving someone wrong—it’s about making the codebase stronger together.

Small changes in tone can:

• Build trust.
• Improve team velocity.
• Elevate engineering standards.

Conclusion

Here, we tried to cover Things NOT to Say in .NET Code Reviews. Effective reviews focus on collaboration, clarity, and continuous improvement. By replacing harsh or dismissive comments with constructive suggestions, teams can improve both code quality and developer experience while fostering a healthier engineering culture.

ASP.NET Core 10.0 Hosting Recommendation

HostForLIFE.eu
HostForLIFE.eu is a popular recommendation that offers various hosting choices. Starting from shared hosting to dedicated servers, you will find options fit for beginners and popular websites. It offers various hosting choices if you want to scale up. Also, you get flexible billing plans where you can choose to purchase a subscription even for one or six months.