Refactor Analysis

TizenFX Refactoring Target Discovery and Issue Registration Pipeline

Overview

A pipeline that scans the TizenFX codebase for .NET 8 and C# 12+ modernization/optimization opportunities, drafts concrete application plans, and automatically registers them as GitHub Issues. Each created issue explicitly states that it is a refactoring objective.

Repository

• Repo: samsung/TizenFX (GitHub)
• CLI: gh CLI (authenticated)

Pipeline Flow

① Auto-select target area and scan → ② Optimization feasibility analysis (Self-Reflection)
  → [Pass] ③ Draft refactoring application plan → ④ Auto-register GitHub Issue
  → [Reject] Discard (low ROI / high risk)

Stage ①: Auto-select Target Area and Scan

Automatic directory rotation logic: Because the scan scope is broad, the scan area is automatically rotated on every run.

1. First run gh repo clone samsung/TizenFX, or git pull the existing clone to sync
2. Collect the main namespace directories under src/:

   ls -d src/Tizen.*/

3. Check which directories have already been analyzed by inspecting existing ai-task labeled issues:

   gh issue list --repo samsung/TizenFX --label "ai-task" --state all --json title --jq '.[].title' | grep -oP '\[Scope: [^\]]+\]'

4. Prioritize directories that have not yet been scanned, but once every directory has been covered once, re-scan starting with the one scanned longest ago
5. Scan only 1–2 directories per run (to allow for in-depth analysis)

Scan Philosophy — 4 Evaluation Lenses (lens-based, not category-based)

Rather than "hunting" for a fixed list of patterns, observe the code through 4 evaluation lenses. A single finding may hit multiple lenses at once; the more it overlaps, the higher its grade.

In priority order:

🚀 Lens 1: Performance (Highest Priority)

The most important lens. Target measurable performance improvements.

• Reduce allocations: ToList/ToArray in hot paths, new inside loops, boxing/unboxing, closure allocation (lambda capture)
• Buffer handling: opportunities to apply Span<T>/Memory<T>, ArrayPool<T>, stackalloc (small fixed size)
• New .NET 8 types: FrozenDictionary/FrozenSet (read-only lookup), SearchValues<T> (char search), CollectionsMarshal
• Task optimization: apply ValueTask (hot path), use IAsyncEnumerable, remove .Result/.Wait() (also prevents deadlocks)
• LOH / GC pressure: allocation patterns for arrays ≥85KB, short-lived large objects

🆕 Lens 2: .NET 8 / C# 12 Modernization

Modernize with the latest language and runtime features.

• C# 12: Collection expressions [1, 2, ..x], primary constructors (class/struct), ref readonly parameters
• C# 11: required members, generic math, raw string literals """..."""
• C# 10~9: file-scoped namespaces, record struct, switch expression, init accessor
• .NET 8 APIs: ArgumentException.ThrowIfNull(x), ArgumentOutOfRangeException.ThrowIfNegative, TimeProvider
• Nullable reference types: introduce #nullable enable, ensure NRT consistency

🧹 Lens 3: Clean Code

Improve readability and maintainability (within internal/private scope).

• Eliminate duplication (DRY), extract common logic
• Split methods that violate single responsibility (one method doing too much)
• Reduce deep nesting / complexity (guard clauses, early return)
• Remove dead code, unused private members
• Improve naming — limited to internal/private only (public API renames forbidden)

📐 Lens 4: .NET Coding Guidelines

Adherence to official guidelines. Based on Microsoft Design Guidelines.

• async/await consistency: remove .Result, .Wait() (cause deadlocks)
• IDisposable pattern: using declaration, consistent propagation
• Exception handling: overly broad catch (Exception), swallowed exceptions, mismatched exception types
• Naming conventions (public APIs are immutable; only internals are in scope)

Lens overlap → grade ↑: if a finding hits both Performance and Modernization, it ranks higher than a single-lens finding (see Stage ②).

Quantitative heuristics (to minimize subjective judgment):

• switch conversion candidates: 5+ case branches, each ≥ 3 lines
• allocation inside loops: new or LINQ chain inside for/foreach
• heavy methods: cyclomatic complexity ≥ 10, or ≥ 100 lines

Stage ②: Optimization Feasibility Analysis and Grade Assignment

2-1. Safety Gate

For each finding, self-verify against the following criteria:

1. Can the Public API Signature be preserved? (no signature changes)
2. Can the Public API Behavior be preserved? (no behavior changes)
3. For Performance-lens findings, is a meaningful benchmark benefit expected?
4. Does it avoid affecting Native Interop / P/Invoke marshalling?
5. Does it maintain Tizen API Level 12+ compatibility? (when using new .NET APIs, confirm support per Tizen API Level)

→ Fails even one of these → discard (low ROI / high risk)