Proper way to name booleans that are A or B not True False

I have a field that indicates whether someone wars a commission or a fee.

In sql its going to be a bit field.

How should I name it?

You might want to use an enum instead of a bool.

public enum Payment
{
    Commission = 0,
    Fee = 1
}

You can then cast it to an integer when necessary.

class Thing
{
    Payment ThingPayment { get; set; }
}

var thing = new Thing();
thing.ThingPayment = Payment.Fee;

int bitValue = (int)thing.ThingPayment;

The simplest thing would be to call it IsCommission (or IsFee). In C# boolean properties should generally start with 'Is' or 'Has' unless the name already implies the boolean nature. If there is a possibility of other values being added to the equation later, seriously consider making it an enumeration now. In that case, you might call it CompensationMethod, but there are quite a lot of good possible names there. If you decide to stick with boolean, which might be a good idea if your database field will remain boolean, you could expose the converse of your property like this:

protected bool isCommission
public bool IsCommission
{
get { return isCommission; }
set { isCommission = value; }
}
public bool IsFee
{
get { return !isCommission; }
set { isCommission = !value; }
}

My 2 rappen, I would have "IsFee" with an extended property to explain it more.

However, at the risk of YAGNI, would have have other types? Such as "retrocession" or "holding fee" as opposed to "payment fee". In which case, a tinyint lookup to another table in SQL.

And as mentioned, a c# enumeration to make things easier.

I would hesitate to use a bit for this. You have a one-to-many relationship going which by coincidence has two possible values. But there could be more relationship values in the future. Somebody might work for free, or require a fee and a commission, or a flat fee if the amount in question is less than a certain fixed amount.

Instead, use a relational table to hold the values. You will give your design more flexibility in the end. You also obviate the need to store any constants in your code.