This post series will be focused on C# and techniques we try to use to maintain high quality code intended to be read by humans. It will be opinionated in favor of readability and intuitive method design. It won’t touch on concerns of extremely high memory or high performance application requirements. These best practices are just practices in general, not hard and fast rules.
A Method can be a lot of things in a software application. What it can be and what the developer writing the calling method expects can be very different. So how do we communicate the behavior of our methods in just a method name?
It’s not easy. We have to rely on some conventions. There is much to consider when calling a method:
- Will it throw exceptions?
- Will it block?
- Will it cause side effects?
- Will it retry?
- Will it be idempotent?
Those five concerns don’t even touch on the reason WHY you want to call the method to begin with. What do you hope to gain from calling this method?
- What will it return to you?
- What will it do for you?
- What does it need from you?
- Does the method require the caller to handle the returned values with special care?
When a developer begins work on the codebase in the future are the caller’s expectations of the method clear and obvious? If they aren’t it is easy for the developer to change the method in a way that defies an expectation of the caller; potentially breaking production code. Some of which is solved by a strong unit test suite.
In the next post, I’m going to talk about how I design C# methods, to communicate how the call should deal with failures or exceptions.
Feel free to comment if you think I missed anything or there is anything in particular you would like to discuss or review.