I am so tired of complex code that can’t be read without having to trace definitions within definitions within references, within Interface definitions within indirection…. until I have no flippin’ idea what is going on.
This is even worse when perpetrated in sample code. Can someone please tell sample code writers that the rule is “make it as simple as possible and demonstrate only one thing; and that one thing is not how clever you are.”
Here’s an actual line of code from an otherwise excellent sample program,
IReadItemsByQueryRequest autocompletedRequest = this.requestMerger.FillReadItemByQueryGaps(
Let’s trace this just a bit, IReadItemsByQueryRequest. This has a nice long name, but it doesn’t quite tell me what it does, so I’ll go to its definition. Guess what, it is an interface that derives from IBaseReadItemsRequest. Following that thread we find out the base implements IBaseItemRequest and has an instance of IPagingParameters. IBaseItemRequest uses four more Interfaces (!).
Returning to our original thread, we see the use of requestMerger’s static method FillReadItemByQueryGaps. This method implements an interface IReadItemsByQueryRequest and takes as a parameter an interface IREadItemsByQueryRequest.
Inside the method are three more interfaces to chase down. And so it goes
Good Code/ Bad Code
While this is “good code” – nicely architected with good separation of concerns and excellent naming (Uncle Bob would be proud) it is opaque.
There is zero chance of reading this and grokking it in less than a couple hours and a couple Advil.
And that is just one method chosen at random.
Please can we simplify? Even at the cost of making it more difficult to reuse the code (which is a myth 99% of the time anyway) can’t we make this code easier to follow?
Your outrage at my heresy may be expressed below in the comments, but only after you decipher this sample application!
Is it us, or is it our Patterns?
PS, I’ve intentionally kept the author anonymous because I’m convinced she/he is an excellent programmer, who is just following the normal, modern patterns. But perhaps it is time to re-examine those patterns.
Latest posts by Guest Posts (see all)
- Kendo UI Customization with CSS - July 14, 2016
- Kendo Grid Custom Column Sort - June 28, 2016
- Creating and Injecting Services – An Introduction to Angular 2 - June 17, 2016
- A Simple Natural Sort - June 16, 2016
- Writing Your First Component – An Introduction to Angular 2 - June 15, 2016