C# Regrets: Top Worst C# Features

Stumbled upon this article written by no other than Eric Lippert listing the top 10 design faults of C# language. Here is the summary,  the source to the full article is at the bottom. 

#10: The empty statement does nothing for me

Reflects on the fact that lone “;” is a legal statement

#9: Too much equality

There are too many ways check for equality: ==, Equals, ReferenceEquals, CompareTo(…).

From personal experience double.NaN == double.NaN is false but double.NaN.Equals(double.NaN) is true

#8: That operator is shifty

Weirdness around << and >> operators

#7: I’m a proud member of lambda lambda lambda

The way C# 2.0 implements anonymous delegates

#6: Bit twiddling entails parentheses

Flags Enums

#5: Type first, ask questions later

C# borrows the “type first” pattern from C and many of its other successor languages – something I got used to and the “correct” way now seems illogical to me

#4: Flag me down

The fact that you can create invalid enum values and have to manually check for this in the code

#3: I rate plus-plus a minus-minus

++i, i++, i +=1 etc. how much confusion and the pain it caused.

#2 I want to destruct finalizers

Agree with the author that finilisers in C# are symptoms of a bug. Seen it way too many times myself.

#1 You can’t put a tiger in the goldfish tank, but you can try

“array covariance” and how this could lead to run-time exceptions.

Source: http://www.informit.com/articles/article.aspx?p=2425867


Definitely something to play with when my brain has more oxygen (suffering from anaemia right now)

Deneme 1 2 3!

AForge.NET  is a C# framework designed for developers and researchers in the fields of Computer Vision and Artificial Intelligence – image processing, neural networks, genetic algorithms, machine learning, robotics, etc.

  • AForge.Imaging – library with image processing routines and filters;
  • AForge.Vision – computer vision library;
  • AForge.Neuro – neural networks computation library;
  • AForge.Genetic – evolution programming library;
  • AForge.Fuzzy – fuzzy computations library;
  • AForge.MachineLearning – machine learning library;
  • AForge.Robotics – library providing support of some robotics kits;
  • AForge.Video – set of libraries for video processing
  • etc.

are mainly topic in this framework. İf you want more information and help  visit: https://code.google.com/p/aforge/

View original post

This sort of code makes me very angy!

Tell me what’s wrong with this simple piece of code:

public class MyService : IMyService, IDisposable 
    private readonly IOtherService _otherService;
    public MyService(IOtherService otherService)
        _otherService = otherService;

    public void Dispose()

The answer is very simple: “I created you and I will be your end”, yet MyService didn’t create IOtherService, thus it has not right to call Dispose() on the service.”

Yet, at Mizuho, I saw many developers lacking this simple, yet critical design concept!


Object Oriented, Test Driven Design in C# and Java: A Practical Example Part #1

Download the code in C#

For a brief overview, please refer to this post.

At this point, many tutorials start by launching into a “Hello, World” style tutorial, with very little practical basis.


This isn’t the most exciting concept, so let’s try a more practical example. Instead of churning out boring pleasantries, our application is going to do something a bit more interesting…build robots.


Specifically, our application is going to build awesome robots with big guns.

Ok, let’s get started with a narrative description of what we’re going to do.

“Mechs with Big Guns” is a factory that produces large, robotic vehicles designed to shoot other large, robotic vehicles. Robots are composed of several robotic parts, delivered by suppliers. Parts are loaded into a delivery bay, and are transported by worker drones to various rooms; functional parts such as arms, legs, etc., are dispatched to an assembly room. Guns…

View original post 876 more words

SOLID principle

Chanmingman's Blog

There is a lot of debate on SOLID principle.

The video Applying SOLID Principles in .NET   (http://channel9.msdn.com/events/TechEd/Europe/2014/DEV-B210) is worth to watch.

I like the last slide Consideration


As he mentioned.

1. Someone just over engineering using the term SOLID

2. How readable for your Dependency Injection if you have large set of object.

3. When talking about maintainable, before SOLID is 50 lines of code, after SOLID is 230 lines of code previewing the same functionality. So you think 50 lines of code is easier to maintain or 230?

View original post

Clean event handler invocation with C# 6

Jon Skeet's coding blog

The problem

Invoking event handlers in C# has always been a bit of a pain, because an event with no subscribers is usually represented as a null reference. This leads to code like this:

It’s important to use the handler local variable, as if instead you access the field twice, it’s possible that the last subscriber will unsubscribe between the check and the invocation:

Now this can be simplified slightly using an extension method:

Then in each event, you can write a single line:

However, this means having a different extension method for each delegate type. It’s not too bad if you’re using EventHandler but it’s still not ideal.

C# 6 to the rescue!

The null-conditional operator (?.) in C# 6 isn’t just for properties. It can also be used for method calls. The compiler does the right thing (evaluating the expression only once) so you can do…

View original post 407 more words

Dependency Injection and highly coupled objects

Coding Journeyman

power-plugI consider that Dependency Injection (DI) is a very helpful pattern, I love to use it in order to reduce the coupling in my code and it helps me when writing unit tests. But sometimes the code depends on objects that are difficult or impossible to mock.

The HttpContext class of the ASP .NET MVC framework is one example of this kind of object.

I created the following Controller and View as examples:

publicclass IndexController : Controller
{[HttpGet]public ActionResult Index(){string[] languages = HttpContext.Request.UserLanguages;return View(model:languages);}}
@model string[]
    Layout = null;
<!--DOCTYPE html>

View original post 759 more words

Custom Naming Convention

The CodeFluent Entities Blog

Since CodeFluent Entities infers a meta-model from your model, before any producer is called to generate a single line of code, a full representation of your application is in-memory. Thanks to this inference step and the resulting meta-model, developers can apply application wide changes.

One of the possible application wide changes is to change the way all database objects are named through a naming convention. By default a set of naming conventions are provided by CodeFluent Entities:

  • FormatNamingConvention
  • LowerCaseNamingConvention
  • UpperCaseNamingConvention
  • DecamelizeNamingConvention
  • DecamelizeLowerCaseNamingConvention
  • DecamelizeUpperCaseNamingConvention

And you can also implement your own naming convention to fit your needs as we’ll see in this post.

Create the custom Naming Convention

The naming convention is a class so we create a class library project and add references to

  • CodeFluent.Runtime.dll
  • CodeFluent.Model.dll
  • CodeFluent.Model.Common.dll

Those DLL are located in the installation folder of CodeFluent Entities.

Create a class that implements IProjectNamingConvention or inherits from an existing…

View original post 63 more words

A Use for Partial Classes/Structs

The keyword partial has been with us for a while now. Until recently I couldn’t find a use for partial classes/structs unless some of the code is auto generated and you want to make sure you don’t interfere with auto generated code. That is until recently I have been asked to create a struct representing a local date – a data that is not affected by time-zones and lacks a time component,

To make it as close as a native CLR type I had to implement a bunch of interfaces, ISerializable, IEquitable<T>, IXmlSerializable. In addition it had to implement some explicit and implicit convertions, !=, ==, >=, <=, > and < operators. Soon, what seemed like a simple struct grew into couple of thousands lines of code,

There is nothing preventing you from putting all the code into one big file, however I think I found a more elegant solution – use the partial keyword and split one large LocalDate by either the interface being implemented or things it’s implementing. So I ended up with:

  • LocalDate.ISerializable.cs
  • LocalDate.IEquitable.cs
  • LocalDate.Operations.cs
  • LocalData.Conversions.cs

I have also used one of the Visual Studio plugins to nest all of those files under a single LocalData.cs.

So far I couldn’t come back with a single draw back of such approach. Please let me know if there are any!

Blog at WordPress.com.

Up ↑