style(guidelines): change function export style to arrow functions

Replace function declarations with arrow function expressions assigned to constants
for better testability when mocking functions during unit tests.

This makes the codebase more consistent and addresses issues with function mocking.

.github/commit-instructions.md

@@ -1,36 +1,81 @@
-# Commit Message Instructions
+# Commit Message Instructions (Conventional Commits)
+
+Commit messages should follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/). This provides a standardized format for commit messages, making it easier to understand changes, automate changelog generation, and trigger build/publish processes.
 
 ## Format
 
-Each commit message should follow this structure:
-
-1. **Short Summary**: A brief summary of the changes (max 72 characters).
-2. **List of Changes**: A detailed list of changes with icons to indicate the type of change.
-
----
-
-### Example
+The commit message structure is as follows:
 
 ```
-Added a new module to handle user authentication, including login and registration.
+<type>[optional scope]: <description>
 
-- ✨ **Feature**: Implemented user login functionality
-- 🐛 **Fix**: Resolved session timeout issue
-- 🛠️ **Refactor**: Improved error handling in auth service
-- 🧪 **Test**: Added unit tests for login component
+[optional body]
+
+[optional footer(s)]
 ```
 
 ---
 
-## Icons for Change Types
+### Components
 
-- ✨ **Feature**: New features or functionality
-- 🐛 **Fix**: Bug fixes
-- 🛠️ **Refactor**: Code improvements without changing functionality
-- 🧪 **Test**: Adding or updating tests
-- 📚 **Docs**: Documentation updates
-- 🗑️ **Chore**: Maintenance tasks (e.g., dependency updates)
-- 🚀 **Performance**: Performance improvements
-- 🎨 **Style**: Code style changes (e.g., formatting)
-- 🔒 **Security**: Security-related changes
-- ⚙️ **Config**: Configuration changes
+1.  **Type**: Indicates the kind of change introduced by the commit. Must be one of the allowed types (see below).
+2.  **Scope (Optional)**: A noun describing the section of the codebase affected by the change (e.g., `auth`, `ui`, `build`). Enclosed in parentheses.
+3.  **Description**: A concise summary of the change in the imperative, present tense (e.g., "add login feature", not "added login feature" or "adds login feature"). Starts with a lowercase letter and should not end with a period. Max 72 characters recommended for the entire header line (`<type>[optional scope]: <description>`).
+4.  **Body (Optional)**: A more detailed explanation of the changes. Use the imperative, present tense. Explain the *what* and *why* vs. *how*. Separate from the description by a blank line. Wrap lines at 72 characters.
+5.  **Footer(s) (Optional)**: Contains additional metadata. Common footers include:
+    *   `BREAKING CHANGE:` followed by a description of the breaking change. A `!` can also be appended to the type/scope (`feat!:`) to indicate a breaking change.
+    *   Issue references (e.g., `Refs: #123`, `Closes: #456`). Separate from the body by a blank line.
+
+---
+
+### Allowed Types
+
+*   **feat**: A new feature for the user.
+*   **fix**: A bug fix for the user.
+*   **build**: Changes that affect the build system or external dependencies (e.g., gulp, broccoli, npm).
+*   **chore**: Other changes that don't modify src or test files (e.g., updating dependencies, build tasks).
+*   **ci**: Changes to CI configuration files and scripts (e.g., Travis, Circle, BrowserStack, SauceLabs).
+*   **docs**: Documentation only changes.
+*   **perf**: A code change that improves performance.
+*   **refactor**: A code change that neither fixes a bug nor adds a feature.
+*   **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
+*   **test**: Adding missing tests or correcting existing tests.
+
+---
+
+### Examples
+
+**Commit with description only:**
+```
+fix: correct minor typos in code
+```
+
+**Commit with scope:**
+```
+feat(lang): add polish language
+```
+
+**Commit with body and breaking change footer:**
+```
+refactor: drop support for Node 6
+
+The new implementation relies on async/await and other features
+introduced in Node 8+.
+
+BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
+```
+
+**Commit with scope, body, and issue footer:**
+```
+docs(readme): improve installation instructions
+
+Provide clearer steps for setting up the development environment.
+Add links to prerequisite tools.
+
+Closes: #12
+```
+
+**Commit with `!` for breaking change:**
+```
+feat(api)!: send an email to the customer when a product is shipped
+```

docs/guidelines/code-style.md

@@ -309,6 +309,7 @@ This section extends the core code style principles with Angular-specific and ad
 
 - **Functions and Methods**:
 
+  - Always export functions as arrow function expressions (const) instead of function declarations
   - Use arrow functions for callbacks and class methods
   - Explicitly type parameters and return values
   - Keep functions pure when possible
@@ -322,16 +323,21 @@ This section extends the core code style principles with Angular-specific and ad
    * @param id - The user's unique identifier
    * @param includeDetails - Whether to include additional user details
    */
-  const getUser = (id: string, includeDetails = false): Promise<User> => {
+  export const getUser = (id: string, includeDetails = false): Promise<User> => {
     // ...implementation
   };
 
   // Bad
-  function getUser(id) {
+  export function getUser(id) {
     // ...implementation
   }
   ```
 
+  // Reason for using arrow function expressions:
+  // 1. More consistent with modern JavaScript practices
+  // 2. Easier to mock in unit tests
+  // 3. Avoids 'this' binding issues
+
 - **Generics**:
   - Use meaningful type parameter names (e.g., `T` for type, `K` for key)
   - Constrain generic types when possible using `extends`