{} Matter!

        [SuppressMessage( "Style", "IDE0011:Add braces" )]
        public int BadlyWrittenCode( ref int x ) {
            if ( foo( ref x ) )
                bar( ref x );
            if ( foo( ref x ) )
                bar( ref x );
                baz( ref x );
            if ( foo( ref x ) )
                bar( ref x );
            else
                baz( ref x );
            if ( ++x < 127 )
                bar( ref x );
            x++;

            //TODO (1 year later..) Was baz always supposed to be called, or is this a bug?
            //TODO (1 year later..) Was x intended to always be incremented, or is this a bug?
        }

Code is for humans to read. By adding these brackets, you make your code’s intention (the LOGIC) clear.

(Note: For those of you in the U.S., “{}” may be called braces. Other parts of the world may call them brackets. They’re the same set! Lol. “<>, (), [], {}”. Open your mind.. Not everyone codes in the U.S.)

We now have the ability to use the new form of using, i.e. “using var outer = new Outer();”. And please use the new format when it makes sense.

But for “if”, “for”, and “while” (and others) you still should use the curly brackets “{” and “}“.

If your braceless code is ever used/refactored again, even by you, the lack of proper brackets will bite with a nasty bug and (more than likely) that will not show up at compile time.

If your argument against using curly brackets is that it’s not worth your time to take the extra milliseconds to type them.. then you’re charging too much. Way too much.

Focus on writing bug free and future-proof code instead of saving keystrokes or minimizing line counts. Personally, I am sick and tired of finding & fixing bugs caused by other people’s laziness (even though I get paid quite well to do so).

Do not write code to the lowest common denominator!

Adding the brackets is so simple, most code formatters can even add them for you.
It’s simply laziness to not add them.

Okay, an example you need? Nah, if you haven’t learned from this example, experience, or an experienced programmer, then learn from Google.. I’m done wasting my time trying to teach you.

You’re still reading? Good.
Do you contest my assertion that adding brackets/braces is always the correct way? Yes? Then show me an example that causes the code to BREAK by adding the proper braces.

I triple double dog dare you.

Ordering of static fields in C# matters

via Ordering of static fields in C# matters

The ordering of static fields does matter.
But per your examples, here is the pattern I always use:

public class Person
{
    private static EmptyPerson _emptyPerson;
    public static Person Empty => _emptyPerson ?? ( _emptyPerson = new EmptyPerson() );
}

The allows the Empty value to be initialized once and read-only, yet still used many times.
It also hides away the requirements of the initialization (the value pulled from a database for example) from the public getter. We could even put the value into a Lazy<Person>().

And in C# 8.0 we now have the compound assignment!

public class Person
{
    private static EmptyPerson _emptyPerson;
    public static Person Empty => _emptyPerson ??= new EmptyPerson();
}

 

Posted in C#

C# Dependency Injection via /r/csharp

via Trying to understand something about Dependency Injection : csharp

User badlife says this:

DI is a lot deeper than you’re thinking. It’s an entirely different way of doing architecture. Here’s a simple example:

Without DI:

  • I’m a component. I need X to do some work. So I’ll create an instance of X and use it. I don’t want Y, or something that looks like X but behaves differently– I want an instance of X and only X.

With DI:

  • I’m a component. I need an instance of X to do some work
    • I’m not going to create an instance of X– I’ll let you give me one when you create me
    • I don’t care if X is really X, as long as it looks like X.
    • I don’t want Y, but if Y pretends to be X, I’ll never know. This is because I only want something that lookslike X.

Here’s an example in concrete terms:

  • The ‘component’ is something that does a calculation. As part of the calculation, it needs to call a web service to get a value (let’s say an interest rate)
  • X is usually a component that calls a web service to get the interest rate
  • Y is a testing component that just returns ‘1.0’ for the interest rate

Without DI, the component is very hard to test because it needs to call a ‘live’ web service to get an interest rate. What if that web service isn’t live? What if it isn’t accessible from the testing environment? The test could be running as part of a build, and the build server might not be able to see the web service.

With DI, both X and Y can implement a common interface. The component doesn’t actually create an instance of X– it just asks for a reference to the interface. So in a real world scenario, the system gives the component a ‘real’ instance of X by passing a reference to its interface. In a testing scenario, the system gives the component a ‘fake’ version of X (it’s actually Y!) also by passing a reference to its interface. The component doesn’t know or care about the internal implementation of what it thinks is X, and can do its work without the web service being available.