@sun-asterisk/sunlint 1.1.7 → 1.2.0

package/origin-rules/dart-en.md

@@ -0,0 +1,289 @@
+# 📘 Dart Specific Coding Rules
+
+---
+
+### 📘 Rule D001 – Keep parameter names consistent when overriding methods
+
+- **Objective**: Maintain consistency between inherited classes
+- **Details**: Do not change parameter names when overriding to maintain consistency in meaning and documentation of parameters if available.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`avoid_renaming_method_parameters`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D002 – Avoid using single cascade (..) operators
+
+- **Objective**: Write clear, readable code
+- **Details**: Only use cascade (`..`) when performing multiple consecutive operations on the same object. Avoid using it for single operations.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`avoid_single_cascade_in_expression_statements`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D003 – Avoid calling methods/accessing properties on dynamic types
+
+- **Objective**: Prevent runtime errors due to lack of type checking
+- **Details**: Avoid using `dynamic.foo()` or `dynamic.bar` without proper checking
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`avoid_dynamic_calls`)
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: critical
+
+### 📘 Rule D004 – Use standard `package:` imports
+
+- **Objective**: Reduce confusion in imports
+- **Details**: Avoid mixing relative and package imports which can cause circular errors or alias errors when a file is imported in two different ways.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`always_use_package_imports`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D005 – Always declare function return types
+
+- **Objective**: Clarify logic and increase reliability in type checking
+- **Details**: 
+  - Avoid `dynamic` returns or unclear type inference
+  - Helps analyzer perform more complete code analysis to find potential runtime errors
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`always_declare_return_types`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D006 – Do not override `==` and `hashCode` in mutable classes
+
+- **Objective**: Prevent logic errors when using mutable objects in collections.
+- **Details**: Equality should be based on immutable values
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`avoid_equals_and_hash_code_on_mutable_classes`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: critical
+
+### 📘 Rule D007 – Do not pass default values when calling functions
+
+- **Objective**: Avoid redundancy and clarify intent
+- **Details**: If a function has default parameters, no need to pass the same value again
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`avoid_redundant_argument_values`)
+- **Principles**: CODE_QUALITY, PERFORMANCE
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D008 – Avoid slow async functions in `dart:io`
+
+- **Objective**: Optimize I/O performance
+- **Details**: Avoid the following slow async functions:
+  - `Directory.exists`
+  - `Directory.stat`
+  - `File.lastModified`
+  - `File.exists`
+  - `File.stat`
+  - `FileSystemEntity.isDirectory`
+  - `FileSystemEntity.isFile`
+  - `FileSystemEntity.isLink`
+  - `FileSystemEntity.type`
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`avoid_slow_async_io`)
+- **Principles**: CODE_QUALITY, PERFORMANCE
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D009 – Do not use throw or control flow in `finally`
+
+- **Objective**: Avoid unexpected behavior
+- **Details**: Do not use `return`, `break`, `throw` in `finally` blocks
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`control_flow_in_finally`, `throw_in_finally`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: critical
+
+### 📘 Rule D010 – Handle all cases when using `switch` with enums or enum-like classes
+
+- **Objective**: Avoid missing cases
+- **Details**: When using `switch` with `enum`, always handle all cases completely.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`exhaustive_cases`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D011 – Avoid importing `.dart` files from `lib/src` of other packages
+
+- **Objective**: Avoid unstable dependencies that cause breaking changes.
+- **Details**: Only import from public API (`lib/src`) within the same package, not from other packages.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`implementation_imports`)
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D012 – Avoid passing null to closure parameters
+
+- **Objective**: Prevent runtime exceptions
+- **Details**: Typically, a closure passed to a method will only be called conditionally, using `null` will lead to exceptions or unexpected logic.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`null_closures`)
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D013 – Use adjacent strings or interpolation to create strings
+
+- **Objective**: Easier to read and more efficient
+- **Details**: Use adjacent strings or interpolation to create strings
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`prefer_adjacent_string_concatenation`, `prefer_interpolation_to_compose_strings`)
+- **Principles**: CODE_QUALITY, PERFORMANCE
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D014 – Use conditional assignment `??=` instead of `if-null-then-assign`
+
+- **Objective**: More concise and clear meaning
+- **Details**: Use `a ??= b` instead of `if (a == null) a = b;`
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`prefer_conditional_assignment`)
+- **Principles**: CODE_QUALITY, MAINTAINABILITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D015 – Use `final`, `const` for immutable variables
+
+- **Objective**: Prevent bugs from unintended value changes
+- **Details**: Use `final` or `const` for variables that don't change throughout their lifetime
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`prefer_final_fields`, `prefer_const_declarations`, `prefer_const_constructors`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D016 – Use explicit definitions for function types in parameters
+
+- **Objective**: Increase clarity and accurate type checking
+- **Details**: Use `generic function type syntax` for parameters.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`use_function_type_syntax_for_parameters`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D017 – Ensure simple and correct Regex syntax
+
+- **Objective**: Prevent logic errors from invalid expressions
+- **Details**: Use clear, simple Regex patterns. Avoid incorrect or overly complex expressions
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`valid_regexps`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D018 – Use `rethrow` instead of `throw` when re-throwing errors
+
+- **Objective**: Preserve original error stack trace
+- **Details**: In catch blocks, use `rethrow` to re-throw the same caught error
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`use_rethrow_when_possible`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D019 – Use `isEmpty` / `isNotEmpty` for String, Iterable and Map
+
+- **Objective**: Clear meaning and better performance
+- **Details**: Instead of `list.length == 0`, use `list.isEmpty`
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`prefer_is_empty`, `prefer_is_not_empty`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D020 – Ensure valid URLs in `pubspec.yaml`
+
+- **Objective**: Avoid metadata errors and poor security
+- **Details**: Do not use `http://` or placeholder URLs like `example.com`
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`secure_pubspec_urls`)
+- **Principles**: SECURITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D021 – Use `BuildContext` synchronously
+
+- **Objective**: Prevent errors when `context` changes after `await`
+- **Details**: Use `BuildContext` carefully in asynchronous functions 
+- **Applies to**: Flutter/Dart
+- **Tools**: `flutter_lints` (`use_build_context_synchronously`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: critical
+
+### 📘 Rule D022 – Place `child:` at the end when constructing widgets
+
+- **Objective**: Help readability of widget tree and UI structure
+- **Details**: Parameters like `child`, `children` should be placed last in widget constructors
+- **Applies to**: Flutter/Dart
+- **Tools**: `flutter_lints` (`sort_child_properties_last`)
+- **Principles**: CODE_QUALITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D023 – Prefer using `contains` for `List` and `String`
+
+- **Objective**: Easier to read and more efficient
+- **Details**: Use `contains` instead of `indexOf` to check for element existence in `List` or `String`.
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`prefer_contains`)
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D024 – Use `??` to convert `null` to `bool`
+
+- **Objective**: Write concisely and avoid null exceptions
+- **Details**: Use `flag ?? false` instead of `flag == null ? false : flag`
+- **Applies to**: Flutter/Dart
+- **Tools**: `dart lint` (`use_if_null_to_convert_nulls_to_bools`)
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major
+
+### 📘 Rule D025 – Include `Key` in Widget constructors
+
+- **Objective**: Help Flutter identify widgets, ensure efficient rebuilds and prevent errors when reordering widgets.
+- **Details**: Use `key` in all public widget constructors
+- **Applies to**: Flutter/Dart
+- **Tools**: `flutter_lints` (`use_key_in_widget_constructors`)
+- **Principles**: CODE_QUALITY, USABILITY, PERFORMANCE
+- **Version**: 1.0
+- **Status**: activated
+- **Severity**: major

package/origin-rules/java-en.md

@@ -0,0 +1,60 @@
+# 📘 Java Specific Coding Rules
+
+### 📘 Rule J001 – Use Null Object or Optional instead of repetitive null checks
+
+- **Objective**: Reduce the risk of NullPointerException (NPE) and avoid repeating `if (x != null)` throughout the code.
+- **Details**:
+    - Encourage using `Optional`, the Null Object Pattern, or guard clauses to handle potential null values.
+- **Applies to**: Java/Kotlin
+- **Tools**: Linter, PR guideline
+- **Principles**: CODE_QUALITY
+
+### 📘 Rule J002 – Do not use `null` as a default value unless absolutely necessary
+
+- **Objective**: Prevent NullPointerException by promoting clearer use of Optional or nullable types.
+- **Details**:
+    - Prefer using `Optional`, explicitly nullable types, or well-defined default values.
+    - Ensure `null` is checked and handled at system boundaries (e.g., during input validation).
+- **Applies to**: Java/Kotlin
+- **Tools**: Static Analyzer
+- **Principles**: CODE_QUALITY
+
+### 📘 Rule J003 – Every enum must provide a clear toString or description when used in UI/logs
+
+- **Objective**: Avoid unclear log messages such as `STATUS_1`, and improve readability.
+- **Details**:
+    - Add methods like `getLabel()` or override `toString()` for enums used in UI or logs.
+    - Avoid default enum output (e.g., raw index or unclear names).
+- **Applies to**: Java/Kotlin
+- **Tools**: Manual Review, Enum Linter
+- **Principles**: CODE_QUALITY
+
+### 📘 Rule J004 – Avoid creating enums/classes just to wrap fixed constants
+
+- **Objective**: Prevent unnecessary abstractions that clutter the codebase.
+- **Details**:
+    - Use enums only when modeling meaningful state, not just as a container for constants.
+    - Reuse existing config/shared constants instead of creating new wrapper classes.
+- **Applies to**: Java/Kotlin
+- **Tools**: Review or static pattern detector
+- **Principles**: CODE_QUALITY
+
+### 📘 Rule J005 – Always use `final` or `const` for variables that do not change
+
+- **Objective**: Clearly express intent and prevent unintended modifications.
+- **Details**:
+    - Variables that are never reassigned should be declared as `final` (Java) or `const` (in other applicable languages).
+    - This helps reviewers, compilers, and future developers understand the variable's purpose.
+- **Applies to**: Java/Kotlin
+- **Tools**: Linter, Static Analyzer
+- **Principles**: CODE_QUALITY
+
+### 📘 Rule J006 – Do not override methods without calling `super` when required
+
+- **Objective**: Preserve expected behavior and side effects in inherited logic.
+- **Details**:
+    - If the superclass method has side effects, ensure to call `super.method()` when overriding.
+    - Only omit `super` if you're completely replacing the logic intentionally.
+- **Applies to**: Java/Kotlin
+- **Tools**: Linter, Manual Review
+- **Principles**: CODE_QUALITY