Comparing Stableford scores across 9, 10 and 18 holes

If your club plays a mixture of round lengths — a summer nine, a winter ten, full eighteens the rest of the year — then any table built on raw Stableford totals is quietly wrong.

This is the kind of error that survives for a whole season because every individual number looks reasonable.

The problem, in one table#

Two members, both playing exactly to handicap every time.

Player A leads by 72 points and neither has played better than the other. A table built on raw sums is measuring how many holes you played.

The same problem appears in averages, form tables, and any “best N scores” rule: mixing lengths means the long rounds crowd out the short ones regardless of quality.

The fix#

Normalise to an 18-hole equivalent:

scaled_points = round(points × 18 ÷ holes)

Now the three rounds are comparable, and the winter ten was the best of them.

The trap: whose hole count?#

Here is the part that is easy to get wrong, and it is a genuine bug rather than a philosophical choice.

Scale by the number of holes the round was played over, not by the number of holes an individual player completed.

Suppose a player walks in after two holes with 6 points.

• Scaling by their completed holes: 6 × 18 ÷ 2 = 54 points. They top the board with a scoring rate nobody has ever achieved.
• Scaling by the round’s length: 6 × 18 ÷ 18 = 6 points. Correctly terrible.

The second is right. A player who did not complete the round did not score well over a shorter round; they scored badly over the round that was played. Scaling per-player turns every abandonment into a leaderboard-topping performance.

So the hole count is a property of the event:

holes = coalesce(event.holes, count(distinct holes with any score), 18)

An explicit value on the event first — the organiser’s declaration, and the only source available for rounds typed in as a single total — then the observed count across the whole field, then a sensible default.

Where scaling applies and where it does not#

This matters, because applying it in the wrong place creates a different error.

Scale when the table is built on scores. Averages, form tables, best-N-scores tables, anything that compares or sums raw points.

Do not scale when the table is built on finishing positions. An Order of Merit that awards 25 points for a win has already normalised — ranking within a round factors out the length of the round entirely. A 10-hole win and an 18-hole win are both wins, and both should pay 25.

Applying scaling to a position-based table does nothing useful; failing to apply it to a score-based table is the bug this post exists for.

The baseline trap that comes with it#

This one bit us directly, and the full story is in we rebuilt our season table three times.

If your table also uses a baseline — a notional score that sits in the pool so members with few rounds are not stranded — the baseline must be on the same scale as the scores.

We shipped a form board with a baseline of 26 points against a club that plays 9 and 10 hole rounds. Real scores were coming in around 20, so the baseline sat above every genuine score and the entire club tied on the same number with “0 of 3 counting”. The board was meaningless.

The instinct is to lower the baseline. That does not fix it: it just moves where the break is, and the 18-hole rounds still count roughly double against the 9-hole ones. Normalising the scores puts the board and the baseline on one scale, and then a single baseline value works for any club and any mix of round lengths.

How to test this#

Two checks that catch essentially every version of this bug:

1. Feed the table a 9-hole round and an 18-hole round of identical quality — 18 points and 36 points, both exactly to handicap. They must produce the same scaled value. Local test data is usually all one length, which is exactly how this reaches production.
2. Feed it a walk-in: a player with 6 points over 2 holes in an 18-hole event. They must appear near the bottom, not the top.