Code Review And Security Audit

Code Review and Security Audit

You are performing code review and security auditing for Guileless Bopomofo.

Scope

This skill covers two complementary concerns:

1. Code Review — correctness, readability, maintainability, and adherence to project conventions.
2. Security Audit — identifying vulnerabilities, unsafe patterns, and potential attack surfaces.

Review Checklist

Code Quality

• Null safety: proper use of Kotlin null-safe operators; avoid !! unless justified.
• Thread safety: correct use of coroutines, synchronized access to shared state.
• Resource management: no leaked cursors, streams, or native resources.
• Error handling: appropriate use of try/catch; no silently swallowed exceptions.
• Consistency: follows existing patterns in the codebase (EventBus for events, ViewBinding for views, etc.).
• No dead code, unused imports, or redundant logic.

Code Smells

• Long methods: methods doing too many things; should be broken into smaller, focused functions.
• Large classes: classes with too many responsibilities; consider splitting by concern.
• Duplicated code: repeated logic that should be extracted into a shared function.
• Deep nesting: excessive if/when/try nesting that harms readability; consider early returns or extraction.
• Magic numbers/strings: unexplained literal values that should be named constants.
• Feature envy: a method that uses another class's data more than its own.
• Inappropriate intimacy: classes that depend too heavily on each other's internals.
• Primitive obsession: overuse of primitives where a domain type (enum, data class) would be clearer.
• Long parameter lists: functions with many parameters; consider grouping into a data class or builder.
• Mutable shared state: prefer immutable data and local state; flag unnecessary var or global mutable collections.

Code Refactoring Suggestions

• Extract method: identify blocks of code within a method that perform a distinct task and can be extracted.
• Extract class/interface: when a class handles multiple responsibilities, suggest splitting into focused classes or introducing an interface.
• Replace conditional with polymorphism: complex when/if-else chains that switch on type can often be replaced with polymorphic dispatch.
• Introduce sealed class/enum: when a set of related constants or states is represented loosely (strings, ints), suggest modeling with a sealed class or enum.
• Use Kotlin idioms: replace Java-style patterns with idiomatic Kotlin — e.g., let/apply/also scope functions, destructuring, extension functions, buildList/buildString.
• Simplify lifecycle management: leverage lifecycleScope, repeatOnLifecycle, or LifecycleObserver to reduce manual lifecycle bookkeeping.
• Reduce coupling: identify tight coupling between components and suggest dependency injection, event-driven patterns (EventBus is already used), or interface abstractions.
• Consolidate duplicate logic: when similar logic appears in virtual and physical key handlers (keys/virtual/ vs keys/physical/), suggest a shared base or utility.
• Improve testability: flag code that is hard to unit test (e.g., direct static calls, hidden dependencies) and suggest restructuring for easier testing.