If you are using an OO language that has polymorphism, it should already be apparent from the method signatures which method you need to call:
bool SaveCustomer(Customer cust)
{
var conn = new DatabaseConnection(connectionString);
SaveCustomer(conn, cust);
}
bool SaveCustomer(DatabaseConnection conn, Customer cust)
{
// Save the customer
}
Sun (and now Oracle) maintained a document titled Code Conventions for the Java Programming Language. The last update to this was in '99, but the essence of the style guide line lives on.
Chapter 9 covers naming conventions.
For an identifier type of 'constants':
The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)
The examples given:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
In a more recent document - its slipped in there. From Variables (The Java Tutorials > Learning the Java Language > Language Basics:
If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names gearRatio and currentGear are prime examples of this convention. If your variable stores a constant value, such as static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.
Many static analyzers for Java seek to enforce this. For example checkstyle enforces:
Checks that constant names conform to a format specified by the format property. A constant is a static and final field or an interface/annotation field, except serialVersionUID and serialPersistentFields. The format is a regular expression and defaults to ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.
This really boils down to the conventions of the community writing the code... and ideally keeping it the same.
The examples above are given as static final ones which are likely derived from the C conventions for #define - which like C, are replaced in the code during compilation rather than at runtime.
The question that then should be asked is "is this behaving like a constant? or is it behaving like a write once field?" - and then following the conventions accordingly. The litmus test for such a question would be "If you were to serialize the object, would you include the final field?" If the answer is that it is a constant then treat it as such (and don't serialize it). On the other hand, if it is part of the state of the object that would need to be serialized, then it isn't a constant.
Whatever the case, it is important to stick with the code style however right or wrong it is. Worse problems erupt from inconsistent conventions within a project than merely something that offends the eye. Consider getting some static analysis tools and configure them to maintain consistency.
Best Answer
Interestingly enough, Microsoft first called it
IXMLHTTPRequestwhen it was first added to the MSXML library.It was Mozilla that used the name
XMLHttpRequestwhen it added the concept into Gecko, implementing the idea to mimic the MS interface. It has since become the defacto standard, tying all other implementations to Mozilla's decision.You'd have to go spelunking in the Mozilla Bugzilla to see if you can find any reasoning for the caps change there, but I suspect that not much thought went into it and the lowercasing of the
ttppart is accidental.This is corroborated by the misspelling of the Microsoft interface in the nsIXMLHttpRequest interface definition (earliest revision in the Mozilla Mercurial repository):