human
J'ai consulté le guide du développeur Apex et j'ai vu la section sur les conventions de nommage qui contient essentiellement ceci :

Nous recommandons de suivre les normes Java pour le nommage, c'est-à-dire que les classes commencent par une lettre majuscule, les méthodes commencent par un verbe en minuscule et les noms de variables doivent être significatifs.

Je recherche quelque chose de plus approfondi, comme terminer tous les contrôleurs par Controller et leurs tests par ControllerTest, etc.
Quel est un bon ensemble de conventions de nommage à utiliser lors du développement sur la plateforme Force.com ? Il serait préférable que la réponse inclue quelque chose qui gère les objets personnalisés, les classes, les pages Visualforce et les composants, et pas seulement les classes Apex
gpt
Suivez les conventions CamelCase de Java, sauf pour les pages VF et les composants qui commencent par une lettre minuscule.

Déclencheurs :
* <NomObjet>Trigger - Le déclencheur lui-même. Un par objet.
* <NomObjet>TriggerHandler - Classe qui gère toutes les fonctionnalités du déclencheur.
* <NomObjet>TriggerTest

Contrôleurs :
* <NomClasse>Controller
* <NomClasse>ControllerExt
* <NomClasse>ControllerTest
* <NomClasse>ControllerExtTest

Classes :
* <NomClasse>
* <NomClasse>Test (Il peut s'agir de classes Util ou de classes de service, ou autre chose).

Pages Visualforce et composants :
* <NomClasseContrôleur>[descriptionOptionnelle] (sans le suffixe Controller). Il peut y avoir plusieurs vues, donc il peut également y avoir un suffixe de description supplémentaire.

Noms d'objets et champs personnalisés :
* Upper_Case_With_Underscores

Variables/propriétés/méthodes en Apex :
* camelCaseCommeJava - plus facilement différencié des champs

Méthodes de test dans les classes de test :
* test<methodOuFonctionnalitéSousTest><DescCourtDuCasDeTest> - Par exemple, testSaveOpportunityRequiredFieldsMissing, testSaveOpportunityRequiredFieldsPresent, etc.

Travaillez-vous sur quelque chose qui sera utilisé comme une application ou dans certains cas simplement comme un projet ? Si oui, suivez les étapes suivantes :

Préfixez tous les objets personnalisés, les classes Apex, les pages Visualforce et les composants avec une abréviation pour les identifier plus facilement (par exemple, plus facile pour les changesets). Par exemple, l'application WidgetFactory aurait le préfixe wf sur ceux-ci. De plus, lors de l'ajout de champs personnalisés à un objet standard, ils doivent également être préfixés pour les identifier comme faisant partie de l'application/package.

La principale raison pour laquelle les noms d'objets et de champs utilisent Upper_Case_With_Underscores est que lorsque vous saisissez le nom du champ ou de l'objet avec des espaces, il ajoute automatiquement les underscores. Bien qu'Apex soit insensible à la casse, référez-vous toujours aux objets et aux champs personnalisés dans le code en utilisant Upper_Case_With_Underscores également pour une cohérence globale et une cohérence avec ce qui est généré par le navigateur de schéma SOQL et d'autres outils. Les libellés d'objet et de champ (qui sont généralement ignorés par le code mais visibles par les utilisateurs) doivent conserver les espaces, sans underscores.