BETTER SOFTWARE DESIGN
The art of turning 6 lines into 92 lines by replacing if-then-else and switch with objects — for the better.
Sure, if-else and switch makes for condense, simple code. But your software should not be comprised of the fewest lines possible, sacrificing readability, maintainability, or flexibility.
I see a lot of branching happening over enums, or, other discrete values. Some developers even get aggravated when told not to use if-then-else.
But, what do you think the consequences of using enums in your if-then-else statement are?
Branching on discrete values makes your software difficult to change. Every new feature requires you to track down where the branching is happening, and modify your existing code accordingly.
This is definitely not how we want to develop great software. It’s perhaps a perfect first step towards making your code work. But, as you progress to making your code better, switch and if-then-else must be long gone. …
PROGRAMMING
Talking about If-else vs. Polymorphism is one way.
It’s honestly quite easy. Basically, anything can tick off a developer. The more “religious” views the developer holds, the easier it is. In my opinion, there’s no culture more toxic than that of developers, programmers, and engineers.
Yeah, there’s even much discussion on when you’re a measly developer — aka code money — an esteemed programmer, or a sanctimonious engineer. Some engineers are furiously agitated when called “developer.”
I’m just going to enumerate a bunch of stuff that really hits home with developers, in no particular order. …
Opinionated Perspective
And lots of them. So, stop boasting about how self-documenting your code is.
Code comments are an interesting topic that’s often subject to heavy debate, and programmers hold almost religious views on the matter. So, I thought, why not have a go at this one, as I do with the whole “not using if-else” and traditional branching.
Commenting on your code is like telling the same story twice. Except, one may get out of sync with reality and starts becoming a lie instead. Code should ideally be self-documenting and annotating it with // or # only increases the signal-to-noise ratio, for the worse.
That’s at least the mindset developers nowadays have converged on.
Many developers thoughtlessly spurt out things like “your code must be self-documenting,” “good code doesn’t need comments,” “commenting code is a bad idea,” or “comments are code-smells.” …
Opinionated Perspective
There’s possibly nothing that has caused more developer-headaches than poor method declarations…
Method declarations are like units of communication between developers. They convey intent and actions.
For the beginner or uninitiated, a method declaration is everything that makes up a method, except for its implementation. That means the access modifier, return type, method name, and parameter list.
This method below looks simple enough. There’s not a whole lot to it.
PRACTICAL DESIGN PATTERNS
How to improve from traditional branching and understanding how the strategy pattern brings down cyclomatic complexity.
Are you struggling with the strategy pattern, or want an extra “take” on how you might go about applying it?
Hopefully, by the end of this article, you’ll have a crisp understanding of how the strategy pattern works, why it’s useful, and perhaps even recognize how custom C# attributes can add value to your application.
Let me just say this right from the get-go, even if your main language is JavaScript, Python, or something obscure like Swift, then I’m sure you’ll find something useful here. You don’t need to be a C# developer to get thru this article.
The strategy pattern is likely one of those first design patterns you’ll ever try to implement yourself. You’ve possibly already implemented this pattern a ton of times before by simply using traditional branching techniques, such as a switch or if-else statements. …
OPINIONATED PERSPECTIVE
Resulting in pain-inducing constructor bloat and incomprehensive object graphs.
Dependency Injection is great. It really is. But, it’s also hell.
The idea of having some IoC container resolve all our explicit constructor object dependencies is amazing and strongly advocated for in the developer community.
And, it makes sense because it simplifies development at design-time.
The approach is essentially like this: make a class. Let it take some dependencies. Register them with the IoC container in a carefree manner. Never look back.
I’m not going to dwell on the details of IoC, DIP, dependency injection, and containers. I’m sure you’re already familiar with the extensive list of provided benefits.
However, there’s a big issue. …
PRACTICAL PROGRAMMING TIPS
Not all code is created equal. And sometimes, garbage code is sufficient code.
Who’s the judge anyway, right?
I’m a design patterns advocate. I like to write neat, clean code, thoughtfully applying design patterns where I see fit. It’s an incredibly rewarding feeling when you correctly and effortlessly implement a design pattern. The opposite is true when forcefully attempting to apply an ill-suited pattern.
Nevertheless, there are times when I simply need to move a user story from In-Progress to Testing. Fast.
Depending on the problem you’re solving, writing garbage code might be completely okay. By garbage code, I mean overly bloated and simple code that does, however, function correctly.
Don’t mistake garbage code for code that doesn’t meet the requirements or fails. That’s insufficient, buggy code, which is entirely different by nature. …
BETTER SOFTWARE DESIGN
How to easily replace if-else statements. And no, a switch is not a suitable substitute.
If you want to learn how I use commands and handlers to keep my code neat and tidy, read on. It’s not about avoiding if-elseif-else. It’s about finding a more suitable approach.
Bear in mind that no single approach will ever get rid of traditional branch-based programming. You need to build a repository of techniques to draw from.
The method we’ll walk thru now is just one of many.
if-else is, at its very core, not bad. It’s merely just a hammer and nail situation we got going. …
Crafting great software is about focusing your attention on what matters at the right time
Rubbish software is produced when we try to do everything at once.
Principles, guidelines, best practices, and rules of thumb — they all make your life easier. Without them, ten-minute tasks can turn into ten-hour tasks.
One of the absolute best pieces of advice I received from my mentor very early on in my career was this simple one-liner:
“Make it work, make it better, make it faster.”
It’s a slight alteration of Kent Beck’s famous quote, and its simplicity is enabling and puzzling.
“Make it work” is quite easy to wrap your head around. You have a set of requirements, and you’re coding to fulfill them — kid stuff. …
It’s easy to refactor messy code once you follow a few simple guidelines
I’ll start by providing you exactly what you came for: the rules of thumb.
Are you curious about why these heuristics are useful? Then read the additional information included after the list.
12 Heuristics for Beginners to Become Refactoring Experts
Let’s dive headfirst into the matter. This list is a mix of heuristics I always have in the back of my mind when I venture into a refactoring session.
- Is your class’ list of parameters starting to grow too big? Then it’s likely doing too much. Its responsibilities are unclear and perhaps painful to test and debug. It’s a prime candidate for refactoring.
- Do you have methods inside classes that only use one of the class dependencies? You better pull that method into a class of its own — even if that class will only consist of a single method. …
