In-Depth
What the Single Responsibility Design Principle Has to Do with C# Best Practices
In this Q&A, highly regarded developer and educator Scott Allen shares his thoughts on coding with C#.
As a development language, C# has clearly made its mark as a clean efficient language with a strong focus on declarative, functional, and component-oriented code. Since its release in 2002, it has become the preferred language of many developers. It's certainly Scott Allen's preferred language.
Scott is a highly regarded C# developer, but is also known for his developer training and education. This year at Live! 360 (coming to Orlando, FL, Dec. 5-9), the veteran Visual Studio Live! presenter will discuss some of his best practices for crafting C# code.
We caught up with Scott to talk about some of the things he'll cover during his session, and to hear some of his thoughts about coding in C# in general, including what he would change if he were part of the C# team at Microsoft.
What is your number one C# best practice?
Many best practices focus on small optimizations or code formatting. I believe the most important practice is to learn and apply the single responsibility design principle.
The single responsibility principle (SRP) says each class should have a single focus and be responsible for a single piece of functionality. Unfortunately, this principle can be difficult to learn. I've been trying to apply SRP since 2004. Every year I think I get a little bit better. I believe SRP makes for smaller classes, smaller methods, and software that's easier to maintain. And here's a related tip: I believe writing unit tests taught me more about SRP than any other activity.
Conversely, what is the number one thing you recommend someone never ever do?
It's difficult to say "never ever do this!" in software development as every project always has some unique qualities. However, I do believe you should never ever work on a C# project with the default build settings. The default settings don't treat compiler warnings as errors, and warnings allow for sloppy code to live. Always go into a C# project after you create the project and find the option to treat warnings as errors.
Why is class cohesion/reducing the coupling between classes so important?
Coupling makes for brittle software. Code that is coupled is harder to change. You can't remove coupling from everywhere, although design patterns like the dependency inversion principle can help. If you know your business well, you'll know what areas of the software are likely to change. Those areas of change are where you need to be careful to avoid coupling.
Is there anything you'd like to see Microsoft change in C#?
I'd like to see Microsoft introduce non-nullable reference types in C#. The proposal is on the table and we might have this feature in C# 7.0. I'd like to get rid of all the boilerplate checks for null references in my code. They add more clutter than value.
For more about Live! 360, go here.
About the Author
Lafe Low has been a technology editor and writer for more than 25 years. Most recently, he was the editor in chief of TechNet magazine. He has also held various editorial positions with Redmond magazine, CIO magazine and InfoWorld. He also launched his own magazine entitled Explore New England, and has published four editions of his guidebook The Best in Tent Camping: New England.