Hi Friends,
I thought of sharing the naming conventions I follow to improve the readability of my OData service for UI developers and other consumers.
| General rules for all artefacts | No "ALL CAPS" |
| Use Camel case | |
| No Underscores | |
| Use English Names | |
| No SAP technical names | |
| Entity Names | Only Nouns |
| Only Singulars | |
| Not to contain operation names | |
 examples | SalesOrderHeader, SalesOrderItem, Address, CostCenter |
 examples: | SALES_ORDER, PO_CREATE, Orders, CostCenterF4, Bukrs, PurchaseOrderList |
| Complex Type | Whenever you have too many fields in your entity, improve the readability of your Entity by grouping fields into Complex Types |
| examples | Complex Type "Address" for complex properties "DeliveryAddress", "PostalAddress" Complex Type "CompensationDetail" for complex properties "OldCompDetail", "NewCompDetail" |
| Entity Sets | Plural of Entity name. Or add 'Set' at the end of Entity name |
| examples: | SalesOrderHeaders, SalesOrderItems, Addresses, CostCenters, Currencies, CurrencySet |
| Navigations | Same as Entity name if the target cardinality is 1 |
| Same as EntitySet name if the target cardinality is M | |
| Reasoning: | Consider two self explanatory, related entities, SalesOrderHeader and SalesOrderItem. Consider the navigation between them named as "SalesOrderItems". Now, to navigate from header to item, we can use a self explanatory URL as below. ..............<ServiceName>/SalesOrderHeader('DummyKey')/SalesOrderItems If you had named the Navigation as say "Header_Item", then you would have called URL ..............<ServiceName>/SalesOrderHeader('DummyKey')/Header_Item which is not at all consumer friendly. |
| Function Imports | Name should clearly Indicate the operation getting performed |
| examples: | ReleasePO, ApproveLeave, BlockSalesOrder, GetReleaseStatus |
Let me know your views and if you follow any other best practices.