> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # The Boolean Parameter Nobody Could Read at the Call Site - URL: https://debugly.dev/reviewing-boolean-parameter-at-call-site/ - Published: 2026-10-09T17:28:00.000Z - Updated: 2026-10-17T05:55:38.000Z - Description: The call passed true and the reader had no idea what true meant, so the behaviour was guessed, and the guess was wrong in the one branch that mattered, and… - Author: Rohit Bhadani - Tags: Code Review, Readability, Design Start at the call and you miss it. Start at the incident and you miss how it arrived. The bug lived in the hand-off. The boolean parameter has a single weak property, and here it is: the call site carries no information about the behaviour, so every reader must leave the call and find the definition, and the leaving is the cost paid on every reading. This was a TypeScript render function, and every language with positional arguments behaves the same way. ## Why the boolean is unreadable The call is the function and the true, and the true is the value, and the value is the not the meaning, and the meaning is the definition's, and the definition's is the elsewhere, and the elsewhere is the search, and the search is the interruption, and the interruption is the cost, and the cost is the every reading, and the every reading is the review and the debugging and the new engineer, and the three are the audience, and the audience is the readability's purpose. The boolean is the binary, and the binary is the two behaviours, and the two behaviours are the different functions, and the different functions are the not named, and the not named is the flag, and the flag is the switch, and the switch is the hidden, and the hidden is the guess, and the guess is the wrong, and the wrong is the incident. The name is the fix, and the name is the parameter's, and the parameter's is the invisible at the call site, because the positional argument does not carry its name, and the not carrying is the readability's absence, and the absence is the cost, and the cost is the reason the boolean parameter is the design smell rather than the formatting choice. ## Why the review passed it The review saw the call, and the call was the syntactically correct, and the correct was the pass, because the type matched and the arity matched, and the two were the compiler's check, and the check was the met, and the met was the miss, because the readability is the not the compiler's job. The review did not ask what the reader learns from this line, and the learns is the nothing, and the nothing is the search, and the search is the cost, and the cost is the review's question, and the question is the readability, and the readability is the fix, and the fix is the question the review should ask of every call site. This is the same review gap as [the money math that used a float](https://debugly.dev/reviewing-money-math-in-floats/), which is why the two fixes look alike. ## The fix, in order **Replaced the boolean with an options object.** The call became the named key, and the named key is the visible meaning, and the meaning is the readable, and the readable is the fix, and the fix is the one parameter, and the parameter is the discipline, because the named key carries its meaning to the call site. **Split the function into two named functions.** The two behaviours became the two names, and the two names are the explicit, and the explicit is the readable, and the readable is the fix, and the fix is the split, and the split is the discipline, because the flag argument is the two functions wearing one name. **Used an enum or a string literal union where more than two cases exist.** The union is the extensible, and the extensible is the third case's absence of the second boolean, and the second boolean is the four combinations, and the four are the untested, and the untested is the bug, and the bug is the fix's target, and the target is the union. **Named the parameter well where the boolean must stay.** The name is the shouldValidate, and the shouldValidate is the hint, and the hint is the partial, and the partial is the better than the flag, and the better is the fix, and the fix is the naming, and the naming is the minimum, because the positional call still hides it. **Added the call-site comment where the API cannot change.** The comment is the true means skip validation, and the means is the readable, and the readable is the fix, and the fix is the mitigation, and the mitigation is the not the solution, and the solution is the signature, and the signature is the discipline. ## The questions that catch it **What does the reader learn from this line alone?** The answer should be the behaviour, and the behaviour is the readable, and the readable is the pass, and the nothing is the fix, and the fix is the naming, and the question is the review's first. **How many behaviours does this function have?** The answer is the two, and the two is the split's candidate, and the candidate is the fix, and the fix is the two functions, and the question is the review's second, because the flag is the two functions' symptom. **What happens when the third case arrives?** The answer is the second boolean, and the second boolean is the four combinations, and the four are the untested, and the untested is the bug, and the question is the review's third. ## What I now do A positional boolean carries no meaning to the call site, so every reader must find the definition to know what the call does. Replace it with a named options object, split the function into two named functions, use a string union when more than two cases exist, and name the parameter well when the boolean must stay. The call read render(data, true) and nobody could say what true did without opening the definition, and the guess was wrong in the branch that skipped validation. Name that one property in review and this class of bug gets hard to ship. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)