SAP UI5 General Coding Guidelines

The following blog explains some of the coding standards that should be followed while coding for SAP  UI5 applications.

1. Routing and navigation:

As far as possible, try to work with navigation using component based routing. Further if an application requires more navigation within split apps like a double master or double detail, use the event bus mechanism. The navigation handling of the event bus should be specific to that split app controller and named uniquely to avoid multiple listeners for the same navigation bus.

2. Developing views in application:

While it is not mandatory that you will have to use only JSViews in all the applications, it is however recommended to use same types of views in the same applications. Different types of views in the same application will lead to problems while writing down the navigation logics.

3. Naming conventions:

The naming conventions for the applications should be as follows:

Variable names: first letter small and followed by camelcase on all the words.

  examples:

• listItem (first letter small and second word first letter capital)
• Listitem (wrong. first letter to be small)
• detailPageController (right)
• detail_page_controller (wrong)

While naming parameters, make sure that the names are expressive and relevant. Too much expressiveness on the variable name is also not encouraged.

Eg. invSplitApp is correct, invoiceOrderSplitAppController is wrong.

Class names:  While it is imperative that the classes be named according to the functionality, it is best to keep the names short. The naming should be first letter capital followed by camel casing for the remaining words.

 examples:

• invMaster
• InvMaster
• inv_master

Always have a naming space convention for these classes. UI5 development by default follows that convention (eg. all classes in login folder to be named as login.ClassName).

Line Spaces: Every variable or local declaration needs to be put in single line as much as possible unless there is some custom filters or mapping or formatting is involved. Put single indentation for all the variables declared.

Function names: All the function names should have a verb as first word stating the general function it does (exception for Formatters and validators). Eg. createContent, getUserDetails. All the functions need to be camel cased (same as variable names). Every function should have a brief description comment above it to state what it does. The description should be brief and should always contain the input variable names and their type.

Referring to elements in Views: For all the JS views, it is recommended to have the elements accessed  as member variables. Usage of global variables for referring to pages or elements is highly discouraged. For all the events on an element, give two inputs: the function to be called and the context element that   is to be given for the function. The context element will be referred as this  inside the function.

4. General Do's and Dont's :

• Never have any variables outside the class (global variables) unless it is cannot be done away with.
• Maintain all the configuration values (like meta data url, etc.) as a config parameter in a separate Service class
• When trying to customize the UI, always use class based styling by adding a new class. Changing the theme classes is forbidden unless the style is applied throughout the application (like font)
• Avoid writing ids for views created in JS views and reusable components (like side menu). You can always refer them as member variables.
• Always have a unique name for id if it's necessary. Copy pasting is alright but always change the id parameter.
• Custom controllers are encouraged for any kind of new functionality that may be out of the scope of UI5.
• Do not use console.log. Use jQuery.sap.log.info() or other levels for debugging purpose.

• Make sure your code is reusable and simple.