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 monkey — 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. …
Attending meeting-filled days wearing blue-light glasses, with a pizza slice in one hand and a dumbbell in the other, striking a perfect balance of endorphins and staying healthy, you wonder how the best developer ever gets any work done.
The secret is, he knows coding is only the last-mile to any solution.
We all know one engineer who seems to have the answers to all and everyone’s questions — or, more importantly, knows how to dig out answers.
The one who knows exactly how to deal with that difficult issue you’re facing, or, can elegantly model a complex domain and…
I’ll just cut right to the chase. No introduction needed.
Look at this method
WithdrawMoney(string accountIban, decimal amount). In a (European) financial system, you’re dealing with IBANs, which is a plain text string looking something like this
Despite being purely text, some stringent rules govern how IBANs are constructed and validated.
Simply using a
string type is communicating to the world — anyone using your code — that any text whatsoever is completely OK to pass in.
This is obviously wrong.
A much better approach is to capture the domain knowledge in a special class and verify that it’s…
You’re not alone if you find OOP difficult and tedious. A simple google search “why is OOP so hard” reveals a ton of dismayed want-to-be developers.
Object-oriented programming is absolutely awesome and paves the way for incredibly flexible, testable, and easy to read code. Though it’s so difficult to get right, and more than usual poor code is produced with OOP.
To a beginner or uninitiated, object-oriented programming seems like a collection of buzzwords that carries little to no intrinsic meaning. …
You’ve probably already done a ton of research on what attributes are, when to use them and why you should care. And let me guess, you’ve met the same old
[Obsolete] attribute over and over…
Let’s do something totally different.
I remember when I first encountered attributes and reflection some years ago, I had absolutely no clue about how they worked, but nevertheless was able to radically change the behavior of my application.
The simple act of consuming attributes was a mystery to me…
Fast forward 5-6 years, I’m using custom attributes to complete my tasks on a daily basis.
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.
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.
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.
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…