Tag Best Practices
YAGNI revisited
I’m starting a new blog post series about the most valuable principles in software development. Not that I think you might not know them, but I rather want to share my personal experience and thoughts on that topic. The order in which I put those principles reflects their significance relative to each other, as it appears to be in my opinion.
That is quite a large subject and I’m going to dilute it with articles on other topics, so it might take a while.
Okay, let’s start.
Make hard-coding your default choice
Hard coding is often considered an anti-pattern. Having values that can change over time hard-coded in the source code requires recompilation every time these values actually change. While this statement is true, I think that hard coding should be the default choice when developing an application. Hard coding vs configuration file When you work on a project or feature, there always are some magic numbers or strings that potentially can change in future.
Interfaces vs Interfaces
Today, I’d like to discuss the differences between interfaces, abstractions and .NET interfaces, as well as what the term "implementation details" means.
Return the most specific type, accept the most generic type
I guess most developers heard the guideline stating that, when designing methods, you should return the most specific type and accept the most generic one. Is it always applicable? Let’s try to look at it from different perspectives.
3 misuses of ?. operator in C# 6
I guess you already know about the safe navigation operator (?. operator) coming up in C# 6. While it’s a nice syntactic sugar for quite a few cases, I’d like to point out some misuses of it I’m sure we will see when C# 6 is released.
Validation logic and NHibernate event listeners
Today, I’d like to discuss a particular case with validating input data using NHibernate event listeners.
Functional C#: Immutability
The topic described in this article is a part of my Applying Functional Principles in C# Pluralsight course. I’m starting a series of articles in which I want to show how to program in C# in a more functional way. Functional C#: Immutability Functional C#: Primitive obsession Functional C#: Non-nullable reference types Functional C#: Handling failures and input errors Why immutability?
Exceptions for flow control in C#
The use of exceptions for flow control was raised quite a few times already (here’s a c2 discussion and here is a great question on SO). I’d like to summarize this topic and provide some common use cases along with code examples to handle them. Exceptions for flow control: why not? Generally, code is read more often than written. Most of the best practices aim to simplify understanding and reasoning about the code: the simpler code, the fewer bugs it contains, and the easier it becomes to maintain the software.
C# code contracts vs input validation
Input validation rules are often taken for code contracts. In this post, I’ll try to cover their differences and show what their common use cases are.
Shared library vs Enterprise development
Most of the development principles are applicable to any software you might develop. Nevertheless, there are some differences between building a reusable library and an enterprise application. Those differences often become sticking points as we try to apply experience gained in one type of project to projects of the other type.
The differences between shared library and enterprise development grow from differences in requirements and lifetime support cycle.
