Diagonal Wires in a Schematic Editor Are Deferred Complexity, Not a Feature

TLDR

Diagonal wires in a diagram editor look like more freedom for the user. Every downstream operation, topology analysis, connectivity queries, BOM generation, auto-routing, export, is harder when wire geometry is not constrained. Enforce orthogonal routing at draw time and every other operation becomes simpler.

What the Industry Does

Most general-purpose diagramming tools allow wires and edges to be drawn at any angle. Figma connectors bend at arbitrary angles. Draw.io has diagonal edge support. Mermaid diagrams route edges wherever the layout algorithm decides. The freedom to draw anywhere is treated as a user benefit.

This is the right choice for general-purpose tools where diagrams are primarily visual artifacts. It is the wrong choice for domain-specific editors where diagrams encode semantic meaning (circuits, data flows, state machines).

Why It Fails for This Problem Class

In a circuit editor, "wire" does not mean "visual line." It means "electrical connection." The topology of the circuit (what connects to what) has to be extractable from the diagram for the diagram to be useful. BOM generation, netlist export, and design rule checks all depend on correct connectivity.

Extracting connectivity from arbitrary-angle wires requires general line-segment intersection tests. A wire near a component port may or may not touch it. The decision depends on the intersection epsilon, which is a tunable parameter rather than a structural guarantee.

Orthogonal wires eliminate the ambiguity: a wire connects to a port if its endpoint falls within the port's bbox. No epsilon tuning. No false positives from near-misses. The constraint is enforced at draw time and the benefit is permanent.

The Better Approach

Enforce the H/V constraint when the user draws, not as a post-process or import-time cleanup:

function snapToAxis(lastPoint, cursor) {
    const dx = Math.abs(cursor.x - lastPoint.x);
    const dy = Math.abs(cursor.y - lastPoint.y);
    return dx > dy
        ? { x: cursor.x, y: lastPoint.y }  // horizontal
        : { x: lastPoint.x, y: cursor.y }; // vertical
}

The user sees the wire snap to horizontal or vertical as they drag. This matches every real-world circuit drawing tool (KiCad, Eagle, Altium) because it matches how electrical engineers think about schematic layout: components on a grid, wires along the grid axes.

What You Give Up

Orthogonal routing forces wires to take longer visual paths. A diagonal wire from (0,0) to (100,100) is 141 units long. Its orthogonal equivalent is 200 units. In dense diagrams, orthogonal wires may require more bends and more crossings than diagonal ones.

For users accustomed to general-purpose tools, the axis-lock can feel restrictive initially. This is a real usability cost, not a theoretical one.

When the Common Pattern Is Right

Allow diagonal wires when: the diagram is a visual artifact (presentation, documentation) rather than an analyzed artifact (circuit, data model). If nobody will ever need to extract connectivity from the diagram, the constraint provides no benefit and the flexibility is worth keeping.

For any editor where the diagram drives downstream operations, the constraint is the feature. The user draws a schematic; the tool extracts the netlist; the netlist drives the BOM. That pipeline only works if the geometry is structured. Orthogonal routing is the structural guarantee that makes the rest of the pipeline correct.