A water-utility meter sync job hard-codes a single plant ID inside the sync function. Crews need the same function for three plants next quarter. Why should the plant ID become a function parameter instead?

Hard-coding a single plant ID inside a water-utility meter sync function couples reusable sync logic to one site. When crews need the same function for three plants, every additional site would otherwise require editing the function body or maintaining near-duplicate copies. Making the plant ID a function parameter decouples site-specific input from the shared algorithm so one function serves multiple plants without rewriting hard-coded values for each run. Callers supply the plant ID per invocation from config, CLI flags, or a plant list. Hard-coding three plant IDs as comments documents nothing executable; comments are not inputs, are easy to drift from reality, and do not make the function reusable across plants. Parameters do not disable logging or confer confidentiality on meter readings; logging and privacy controls are separate concerns from parameterization. Claiming parameters hide readings confuses design patterns with security controls. Function parameters also do not replace source control. Version history, peer review, and rollback remain necessary for utility scripts regardless of how plant IDs are passed. Exam caveat: prefer validating the plant ID (allow-list of known plants) at the boundary so a typo cannot sync the wrong facility; parameterization enables reuse but does not by itself enforce authorization or plant existence. Operational check: invoke the sync once per plant with distinct parameters, confirm each run targets the intended plant meters, verify no residual hard-coded single-plant constant remains in the function body, and review logs for the plant ID on every execution so operators can audit multi-plant batches.