Following a hard rule for naming conventions in software development is difficult; it's always a compromise between how things were named in the past and where things are going in the future. Other dependencies like the size of the project, the number of developers, and the environment you’re developing in play important factors. In short, there’s never a great naming rule, but here’s my general (heuristic) approach to naming.

My heuristic approach to naming conventions:

New Development / Greenfield Work:

• Follow the conventions of the language, or the standards used within the larger community, and pay attention to the API. For example: If you’re programming in .NET follow the naming conventions outlined in MSDN, in JavaScript look at the DOM API, in CSS look at the definitions.
• If a formal naming convention exists for the organization and these conventions makes sense (they aren’t too far off the language APIs) then follow them. If it feels like the naming conventions were created in the dark ages by a very-very senior COBOL Developer then start asking questions.

Maintenance / Brownfield Work:

• Follow the conventions of the existing code if you’re modifying an existing module.
• If you’re creating new modules then consider following the conventions of the language and API.

This post was inspired by a podcast by Donald Belcham and Kyle Baley on Brownfield Applications.