Naming Conventions: amountPaid vs. paidAmount

Question

Howdy all,

here is two samples with two different approaches to naming variables:

decimal amountDue = 1000;
decimal amountPaid = 800;

vs.

decimal dueAmount = 1000;
decimal paidAmount = 800;

Which one would you usually prefer and why?

Answer 1

The first one (amountDue) means typing seven characters before getting useful intellisense. I'd opt for number two.

Answer 2

"Paid" has several attributes: paidAmount, paidDate, paidBy, paidTo, etc.

"Amount" is the data type (essentially currency or BigDecimal or whatever your language uses) and doesn't mean much.

Answer 3

http://wordsmith.org/anagram/anagram.cgi?anagram=amount+paid&t=1000

Answer 4

You should use which ever one reads better as an english sentence. Such as the amount due to the customer is 1000 dollars. In my opinion #1 is better. Because if you write the customer is due the amount of 1000 dollars, it breaks up the wording of the actual variable.

Answer 5

To stir the pot a little (and there's no fun if everyone agrees), I would choose option 1.

• it indicates to me they are related
• it's the natural way of saying it.

Answer 6

Whatever is most readable in the given context. I could see this ranging from either of your options to simply "paid" and "due".

For example:

public decimal RemainingAmount( Invoice invoice, int quantity, Coupon[] coupons )
{
     decimal paid = coupons.Sum( c => c.Value );
     decimal due = invoice.Price * quantity;

     return due - paid;
}

Answer 7

As others said, option #1 is better as naming follows how one would use those concepts in a sentence without sounding weird. However, I think you should also pay attention the business domain that you're modeling to name your variables. A concept may be referred to with a very unique name or terminology in a particular business domain that would not sound right when used in a sentence out of that business domain. If this is the case, then I would go with the terminology that the business domain is using so that the code is expressed in business domain terminology. This helps developers getting familiar with the business domain and also makes communications with clients easier as everyone speaks the same language.

For example, in this particular case, if I notice that the business documents and cliens are using due amount instead of amount due in referring to a payment expected, I would go with due amount.