Code Quality Analysis

Technical Audit: RSI & Z-Score Speedometer¶

1. Architectural Efficiency & Optimization¶

The script’s architecture is novel, using historical bar times to construct a static x-axis for drawing complex shapes. While creative, this approach introduces significant performance challenges.

• Computational Footprint: The primary performance bottleneck is the massive churn of drawing objects. On every bar, the script creates and immediately deletes hundreds of line and label objects.

  • The f_draw_sector function contains a for loop that draws a series of small line segments to create an arc. With 10 calls to this function per speedometer, and each call potentially creating 20+ lines, this alone generates over 400 line objects per bar.

  • Combined with ticks, labels, and needles, the script manages approximately 420+ lines and 12+ labels on every single tick update. This is extremely resource-intensive and will cause noticeable lag and high CPU usage, especially on lower timeframes (e.g., 1-minute) or on complex instruments.

• Redundant Calculations: The x_axis1 and x_axis2 arrays are rebuilt from scratch on every bar. While necessary for the “rolling” nature of the visualization, this contributes to the computational load. The core issue, however, remains the drawing object management, not the array manipulation.

• max_bars_back Usage: The script requires a large historical buffer to access past time values (e.g., time[214] with default settings). Pine Script automatically infers this, but it increases memory consumption. This is a direct and unavoidable consequence of the chosen architectural design.

Optimization Recommendation: A more performant architecture would involve managing a persistent set of drawing objects. Instead of delete/new on every bar, the script should create the static components (sectors, ticks, labels) only once using var objects. Dynamic elements like the needle could then be updated using line.set_xy() and label.set_xy(). This would reduce the per-bar computation from hundreds of object creations to just a few object modifications, yielding a performance improvement of several orders of magnitude.

2. Modern Standards & Syntax Audit¶

The script is written in Pine Script v5 and uses modern syntax for inputs and color handling. However, it misses opportunities to leverage more advanced v5 features for better structure and maintainability.

• Legacy Check: The code is fully compliant with v5 standards. There is no legacy syntax from v3 or v4.

• Missed Opportunity for User-Defined Types (UDTs): The script’s structure is a prime candidate for abstraction using UDTs. The entire logic for a speedometer—its radius, position, colors, and drawing methods—could be encapsulated within a type Speedometer.

  • Example UDT Structure:

    type Speedometer
        int radius
        int center_time
        array<int> x_axis
        // ... other properties
    
        method draw_sectors() =>
            // ... logic to draw sectors
        
        method update_needle(float value) =>
            // ... logic to update the needle line

  • Using a UDT would eliminate the massive code duplication seen in the global scope for drawing the RSI and Z-Score speedometers, making the script dramatically cleaner and easier to maintain.

• Arrays: The script makes effective use of arrays to store the time coordinates for the x-axis, which is a correct and modern application of this feature.

3. Logic Integrity & Reliability¶

The script’s core indicator calculations are sound, but it contains a critical runtime vulnerability.

• Repainting & Future Leaks: The script is non-repainting. Although it uses historical bar data (time[i]) to position the speedometer display, the indicator values (rsi_metric, z_metric) that determine the needle’s position are calculated using standard, non-forward-looking functions (ta.rsi, ta.stdev). The visual elements are drawn in the “past” relative to the most recent bar, which is a valid and stable visualization technique.

• Calculation Stability:

  • Critical Flaw (Runtime Error): The script does not handle na values returned by ta.rsi() and ta.stdev() during the indicator’s initial warmup period. The rsi_metric and z_metric variables will be na, and passing them to the f_draw_needle function eventually leads to math.round(na). This operation is illegal and will throw a runtime error, disabling the script until enough bars have loaded.

    • Fix: All drawing functions that depend on calculated metrics must be wrapped in a check, such as if not na(rsi_metric).

  • Division by Zero: The Z-Score calculation correctly includes a check for z_std != 0.0, preventing a division-by-zero error. This is a good example of robust coding.

4. Readability & Maintainability¶

The script suffers from poor readability and high maintenance overhead due to code duplication and unclear naming.

• Naming Conventions: While top-level variables are well-named (rsi_len, z_limit), the function parameters are cryptic (e.g., _xa, _sn, _ts, _ll). This forces anyone reading the code to reverse-engineer the function’s purpose from its implementation, violating clean code principles.

• Documentation & “Magic Numbers”: The functions lack comments explaining their parameters. Furthermore, the main drawing section is filled with “magic numbers” (e.g., f_draw_sector(x_axis1, 1, 5, 20, ...)). It is impossible to know what 1, 5, or 20 represent without deep analysis. These should be replaced with named constants (e.g., SECTOR_COUNT = 5) for clarity.

• Code Duplication: The blocks of code for drawing the RSI and Z-Score speedometers are nearly identical. This is a significant maintenance burden; any change to the speedometer’s appearance (e.g., changing a color or tick mark) must be manually duplicated. As noted in Pillar 2, this is the exact problem that User-Defined Types are designed to solve.

Audit Verdict¶

Code Quality Grade: C

The “RSI & Z-Score Speedometer” is a visually impressive and functionally creative script that demonstrates a clever, non-repainting approach to building complex graphical displays. However, its technical foundation is compromised by severe architectural inefficiencies and poor maintainability practices.

• Greatest Technical Achievement: The core concept of using an array of historical time values to construct a stable x-axis for a semi-circular gauge is an ingenious solution to a common visualization challenge in Pine Script.

• Most Significant Technical Debt: The script’s performance is critically flawed. The practice of creating and deleting hundreds of drawing objects on every bar update is architecturally unsound and leads to extreme computational inefficiency. This, combined with the high degree of code duplication and a critical na-handling bug, makes the script brittle and difficult to maintain or build upon.