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 canuse 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.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply