If most people don't mind along with the senior
developer then you will have very difficult time persuading them all. In this
case I would recommend just keep going with the original convention set forth
by the original developer and at least keep things consistent.
If other people are not okay with that as well then
you can focus on the ROI of converting already existing project naming
convention to language naming convention and present that to the
management along with the senior developer. This will most certainly cause some
friction.
In conclusion, I would say that language naming
conventions are very important because new people coming into your project are
more comfortable with the code-base requiring less explanation and causing less
friction.
The reason being that language naming conventions are
global and project naming conventions are local so people would need more time
getting used to it.
As new developers are getting used to the project
naming conventions they are bound to mix it up with language naming conventions
if that's what they were used to. Code reviews could solve this issue but it is
an unpleasant element of going with the project naming conventions
nevertheless.
Hence, from that perspective language naming conventions
are more important than project naming conventions.
Follow the CamelCase Java conventions, except for VF
pages and components start with a lower case letter.
Triggers:
- § <ObjectName>Trigger - The trigger itself. One per object.
- § <ObjectName>TriggerHandler - Class that handles all functionality of the trigger
- § <ObjectName>TriggerTest
Controllers:
- § <ClassName>Controller
- § <ClassName>ControllerExt
- § <ClassName>ControllerTest
- § <ClassName>ControllerExtTest
Classes:
- § <ClassName>
- § <ClassName>Test (These might be Util classes or Service classes or something else).
Visualforce pages and components:
- § <ControllerClassName>[optionalDescription] (without the suffix Controller). There might be multiple views so could also have an extra description suffix.
Object Names and custom Fields:
- § Upper_Case_With_Underscores
Variables/properties/methods in Apex:
- § camelCaseLikeJava - more easily differentiated from fields
Test methods in test classes
- § test<methodOrFunctionalityUnderTest><ShortTestCaseDesc> - For example, testSaveOpportunityRequiredFieldsMissing, testSaveOpportunityRequiredFieldsPresent, etc.
Working on something that would be used as an app or
in some cases just a project? If yes, then do the following:
Prefix all custom objects, apex classes, Visualforce
pages and components with an abbreviation so that they are easier to identify
(e.g., easier for changesets). For example the WidgetFactory app would have the
prefix wf on those. Additionally, when adding custom fields to a standard
object they would also be prefixed to identify them as part of the app/package.
The main reason for the Object and Fields Names using
Upper_Case_With_Underscores is that when you type in the name field or object
with spaces it automatically adds the underscores. Although Apex is case
insensitive, always refer to the Objects and Custom Fields in the code as
Upper_Case_With_Underscores as well for consistency all around and consistency
with what is generated by the SOQL schema browser and other tools. Object and
Field Labels (which are generally ignored by code but visible to
users) should keep spaces, not underscores.
