Ask Specific Questions....

You might think the two if statements below are the same thing...



But if myCollection conforms to an interface, which has both Count and IsEmpty properties declared, then use IsEmpty if you mean IsEmpty.

I'm not for a moment suggesting that Count==0 will not reliably determine that the collection is indeed empty. But what if the object that implements the interface is a linked list, which implements count by iterating over the nodes?

No-one would do that. Would they?

What if it was some form of virtual collection.... Count may be quite expensive. And all you care about are two cases Count == 0 and Count > 0.

It's an unlikely side effect.

But in general, if someone has gone to the trouble of giving you a specific function, use it. They may have had something in mind when they wrote it.

Your code will be, if anything slightly clearer, there's very little down side.

Say what you mean

Prefer Specific things.
Like Empty



It's a bit better than



It's most likely implemented as a static, so you don't have to allocate an empty list.
It shows clarity. You intend to return a empty collection. No one will ever wonder if you had omitted to add something to the list.

YAGNI

You Ain't Gonna Need It


Or perhaps, Einstein said it better "Make everything as simple as possible, but not simpler.".


There are many tools at our disposal when we write code. And once we get to know about a new tool, we tend to use it. We often use it a lot. Too much in fact.

To make it just that little bit more confusing...

Some people seem to have developed a habit of reversing comparisons to keep the Constant at the front.

So

If (itemCount > 0) {...  becomes If (0 < itemCount) {...

Yield

Yield - does not play well with recursive algorithms

In c# they introduced a thing called yield. If you have not come across it before, then you can do such things as this:



public override IEnumerator<T> GetEnumerator()
{
    int count = Count;
    for (int i = 0; i < count; ++i) {
        yield return this[i];
    }
}

And now, c# automagically creates an enumerator object and manages the state of this enumerator for you. There's a small cost, but usually it does not matter.

The Confusion Index

At some point many months after you write you code, you will have to go back and change it. Or someone else will. And then a while later, someone else will change it again.
That someone will be picking their way through your code to find why it is broken, or to find the place to add a new feature.

As they pick their way along, your code may be clear, concise, or it may be misleading and confusing.

How Big should a Class be?

It's a common question - how big should the class be? Should I break it into smaller classes? Am I making things overly complex by splitting it out.

I will say that I am not sure I have ever seen source code where the classes were consistently too small.

Let us take a trivial example:

Say we have sensor, and it holds it's readings in a list. (I know there should be timestamps etc, but we are limited by how much I'm prepared to type, and by how much you will read)

Change

Way back a long time ago, I wrote some code to use a neural network to deal with the Kinematics of a robot arm in 2 dimensions. In nearly 20 years, no-one has ever needed to change a single line of that code.

However, that is entirely because it was my final year college project, and it has not seen the light of day since I showed it to the professors all those years ago.

If people use your code, then the requirements will change. And you will have to change the code. This is as certain as any physical law, and as true as any mathematical proof. It is unavoidable.

Don't reformat code....

So, the old brackets argument....

if (x==0) {
    // Do Something here
}


or 

if (x==0) 

{

    // Do Something here

}

Well here's the answer. They are both fine. Leave 'em  be.

And here's why.

It depends....

Some details may have been changed to protect the innocent naive. 


"So all I wanted was a simple program to send a formatted message over a particular network protocol. Just a little test program.
No problem. I have code that builds that message, it's in a utility library. It'll just take a moment.

Names are powerful things.

Read the list of colours, but try to call out the colour, not the word.

Red, Blue, Green, Yellow, Green, Red, Blue, Yellow

Names are powerful, they live in our head, and tell us things, we believe them, even against strong evidence.