# Coding & Formatting Rules

The user expects strict adherence to the following coding, formatting, and behavioral rules in this repository:

## General Formatting
1. **Double Quotes:** Use double quotes (`"`) instead of single quotes for all strings and imports.
2. **Sort by Length:** Sort arrays, object properties, and import statements from **longest to shortest string length** (uzundan kısaya). For JSON objects or key-value pairs (like translations), sort by the **combined length of the key and the value (key + value)** from longest to shortest. This is a strict visual aesthetic preference. This applies deeply to destructured imports, props, array data, and types as well.
3. **Line Breaks (Newlines):** Pay attention to line breaks. Add new lines between imports and JSON object keys where appropriate. ESLint rules regarding newlines must be strictly followed.
4. **Hook Spacing:** Always leave a blank line between each distinct hook call (e.g. `useContext`, `useState`, `useNavigation`, `useLayoutEffect`). Do not group them tightly together without empty lines.
5. **Array Destructuring:** When destructuring arrays (such as from `useState`), place the opening bracket on one line, each destructured item on its own separate line, and the closing bracket on its own line.
   Example:
   ```typescript
   const [
       title,
       setTitle
   ] = useState<string>("");
   ```
6. **Main Component / Object Export:** Always define the main component or object as a variable/arrow function (e.g., `const PageName = () => { ... }` or `const stylesheet = StyleSheet.create({ ... })`) and place the `export default PageName;` or `export default stylesheet;` at the very bottom of the file. Do not use `export default function PageName()` or inline `export default StyleSheet.create(...)`.
7. **Top-level Blank Lines:** Top-level variables, arrays, types, and functions located *outside* of the main component must be separated by an empty line. Do not group them without new lines.
8. **No `any` with `localize`:** Never use `as any` when calling the `localize` function (e.g., use `localize("key")` instead of `localize("key" as any)`). The `any` type is strictly forbidden.
9. **String Interpolation:** Use template literals (`` `${...}` ``) for string concatenation instead of the `+` operator.

## Tooling & Checks
1. **ESLint Validation:** Habitually run `yarn run eslint --fix <file>` or `yarn run eslint <file>` after making code edits to ensure strict ESLint compliance.
2. **TypeScript Validation:** Habitually check and respect TypeScript compiler errors (e.g., using `tsc` or IDE feedback). Do not ignore `any` or strict typing constraints.
3. **No External Formatters:** Do not introduce Prettier or automatic scripts that might break these explicit manual formatting rules. Format code block by block meticulously.

## Behavior
Always follow these rules by default. Pay "extreme attention" (aşırı dikkat) to the sorting rules, ESLint, and TS constraints during modifications.

## Strict Batch Operations Ban and Multi-Angle Verification
- NEVER use `multi_replace_file_content` or attempt to edit multiple files in a single pass. The user explicitly bans batch operations ("Toplu işlemi yasaklıyorum").
- Any fix or change MUST be done one-by-one, meticulously.
- Before applying any change to a file, verify the exact location, context, and potential side effects from at least 3 different angles (e.g., check exact lines using view_file, consider how the component uses the prop, and anticipate how the linter will react).

## Semantic Naming for Styles
- When defining styles in `stylesheet.ts`, you MUST use semantic naming based on the object or component being styled, NOT based on the style values.
- **Incorrect:** `flex1`, `fullWidth`, `transparentBackground`
- **Correct:** `container`, `content`, `titleContainer`, `title`, `emptyCheckIcon`
- For example: The outermost `<View>` in a component is usually `container`. A wrapper for content is `contentContainer`. A view wrapping a title is `titleContainer`. Always look at the semantic purpose of the element in the UI hierarchy.

## Line Endings (CRLF)
- Always use Windows-style CRLF line endings (`\r\n`) for all text and code files, unless a specific file or environment strictly requires LF (`\n`).


## No Inline Comments
- Never leave inline comments in the code explaining what the style or line does.
- Remove all inline comments unless they are strictly necessary (e.g., leaving something broken intentionally to fix later).
- Keep the codebase clean and free of conversational or explanatory comments.

## Communication Language
- ALWAYS communicate in Turkish (Türkçe konuş) with the user in all responses, explanations, and notes, unless strictly required otherwise.
