feat: Add format options to llm guidelines

Author: 1110101

resources/guidelines.md

@@ -44,7 +44,11 @@
     ```
   - Find more information on the UI5 documentation page "Declarative API for Initial Components"
 - **ALWAYS** use data binding in views to connect UI controls to data or i18n models.
-  - When binding data from OData services, **NEVER** use custom formatters for standard data types (e.g., dates, numbers, currencies). The built-in types handle these cases automatically.
+- **ALWAYS** prefer built-in data types with format options for formatting in data binding:
+  1. Built-in Data Types with Format Options: Use built-in data types (e.g., `sap.ui.model.type.Integer`, `sap.ui.model.type.Currency`) with `formatOptions` to handle standard formatting needs. For OData models, the types in the odata namespace are used (e.g., `sap.ui.model.odata.type.Decimal`).
+     - Example: `sap.ui.model.type.Integer` with `formatOptions: {groupingEnabled: true}` for number formatting with thousands separator.
+  2. Custom Formatters: Only write custom formatter functions for unique business logic that cannot be handled by built-in data types and their format options.
+  - This applies to **ALL** data sources (OData models, JSON models, etc.). Built-in data types can handle standard data types (dates, numbers, currencies, etc.) and should always be preferred over custom solutions.
 - When making changes to `*.properties` files, **ALWAYS** apply the changes to all relevant locales. This ensures consistency across different language versions of the application.
   - **Example:** If you add a new key to `i18n.properties`, also add it to existing translation files like e.g `i18n_en.properties`, `i18n_de.properties`, etc.
 - **NEVER** use inline script in HTML