Coding & Formatting Rules

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

General Formatting

Double Quotes: Use double quotes (") instead of single quotes for all strings and imports.
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.
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.
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.
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:
```
const [
   title,
   setTitle
] = useState<string>("");
```
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(...).
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.
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.
String Interpolation: Use template literals (`${...}`) for string concatenation instead of the + operator.

Tooling & Checks

ESLint Validation: Habitually run yarn run eslint --fix <file> or yarn run eslint <file> after making code edits to ensure strict ESLint compliance.
TypeScript Validation: Habitually check and respect TypeScript compiler errors (e.g., using tsc or IDE feedback). Do not ignore any or strict typing constraints.
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.

AGENTS.md 4.0 KB Előzmények Nyers