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. …
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. …
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.” …
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.
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. …
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. …
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. …
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. …
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. …
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.
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.