How would you set a codebase-wide standard for point-free style when half the team reads it fluently and half does not?

## Why this is a readership decision Point-free style has no runtime consequence worth arguing about. Its entire effect is on the people who read the code, which makes a split team the decisive fact rather than an inconvenience. Half the team resolves a chain of combinators as fast as a sentence; half stops and decodes. Any standard that ignores that asymmetry is really a standard about whose reading speed counts. The second decisive fact is that style rules are enforced in code review by people under time pressure. A rule that requires judgement gets argued, and an argued rule gets applied inconsistently, which is worse than either answer applied uniformly — the codebase ends up with both styles *and* the review cost. ## Make the rule checkable The practical move is to convert the judgement into something visible in a diff: 1. **Erase an argument only where the rewrite introduces no new function.** If the diff adds a combinator that routes a value, the parameter stays. This is readable off the change itself. 2. **Every stage in a chain is a named step.** No anonymous inline functions in a chain that claims to be point-free; if the steps are unnamed, nothing is named. 3. **Every boundary must be nameable.** A reviewer should be able to say what the value between two stages is. If nobody can, split the chain and name the seam. These three are not arbitrary. Each one targets a specific way the style fails, and each one can be answered yes or no without knowing the reviewer's fluency. ## Scope it rather than universalising it | Where the code lives | Rule to apply | Why | |---|---|---| | Widely-read shared helpers | The conservative rule, strictly | Read by everyone including new joiners; the slowest reader sets the cost | | A specialised module with a settled owner pair | Room to go further | The readership is small, known and fluent | | Glue at a system boundary | Prefer the pointed form | Read most often under incident pressure, where decoding is expensive | | Test code | Pointed, almost always | The point of a test is to be read literally, not compressed | This is the part most teams skip, and it is where most of the value is. A single universal rule has to be set at the level of the least fluent reader of the most-read file, which makes it needlessly conservative everywhere else. ## Do not mandate a migration The reflex after agreeing a standard is to apply it to everything. Resist it. A repo-wide restyling produces a large diff that changes no behaviour, and review attention is the scarcest resource on the team: spending it on a change that cannot introduce a bug it could also catch is a poor trade, and a diff that large is reviewed by scrolling. Apply the standard to new code and to definitions you are already editing for another reason. The codebase converges on the working set, which is the part being read anyway. ## What to do about the fluency split itself The standard is a stopgap for a knowledge gap, and it is worth saying so out loud. Two things actually close it: a short written page giving the vocabulary and the three rules with examples from your own code, and the habit of writing the pointed form in the review comment when asking for a change, so the reader sees the two side by side. Neither is a mandate. What does not work is assuming a style guide transmits fluency; people learn the vocabulary from code they had a reason to read. ## How you know it worked Count the right things. The wrong metric is how many definitions lost their parameter — that measures compliance, not benefit. The signals worth watching are whether style comments on this subject drop out of review, whether new joiners raise questions about specific chains, and whether the incident-time reading of boundary code got faster or slower. If the arguments keep happening, the rule was not checkable enough; if a specific module keeps generating questions, the scope was wrong there, not the rule. And it is a legitimate outcome to conclude that the answer for your team is "pointed by default, argument erased only where the rewrite adds nothing" and to stop there — a narrow standard that is actually applied beats a sophisticated one that is negotiated weekly.