Today, I had a colleague question my use of a state object. He was just asking questions about its usage and other general questions about the code I wrote and how to refactor it. He wasn’t slamming my code or anything, but it made me remember the times my code has been slammed by someone that thought differently than me about coding.

Like many developers, having other people review your code can be a little hairy. I feel like I am waiting on a judgement to be reached and a sentence to be passed down. I’ve always hated having to hear from the code reviewers that thought nothing of writing a 100+ line method or 800+ line class. Those “just make it work” aficionados that made my life hell when I had to maintain their monsters by bolting more shit on top of shit and praying a new bug isn’t introduced.

Now, I don’t give a hoot what you think about my code unless you can give me a solid argument on why I should change it. Not saying I am a perfect coder, but I know there are a thousand ways to code the same thing. Some ways are better than others, but I’m not changing for change sake to appease your sensibilities. You have to provide proof that my code is so terrible that I have to go in a change it.

For example, I don’t like holding public state in a class that performs logic because you never know who will change the state. I will still have public read/write properties from time to time, but it always feels dirty when I do. So, I pass state through a constructor to readonly properties or through public method parameters. I don’t like having more than four method parameters, so I will create a plain old C# object (POCO) with no logic to hold state that I can pass to methods. I don’t like methods that do more than one thing (with thing being defined by me) and I like expressive sometimes long method names.

After years of learning about patterns, SOLID, DDD, functional programming and more, this is just how I naturally roll now. I don’t even think about it anymore. It just instinctively drives my fingers as I code in some zen state of mind. Does it create complexity, yes. Do I still write bugs, yes. Does it make the world a better place, no. I’d rather deal with the complexity and simple logic bugs than a bug related to some weird and unknown state mutation with error messages two times removed from the root cause of the damn bug.

You can complain about all the small methods I write that are doing one thing exceptionally well. You can roll your eyes while you have to follow a bunch of method calls with long names that explain what they do. I’m not changing the way I think about this anytime soon. So, if you ever have to read my code… suck it up deal with it and run the unit tests as you try to make it better. 🙂