# Form variable length & name warning **URL:** \ **Category:** Development\ **Tags:** configuration, cht-conf\ **Created:** [March 24, 2026, 2:07pm UTC](https://forum.communityhealthtoolkit.org/t/form-variable-length-name-warning/5541 "2026-03-24T14:07:20Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Anro](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/anro/32/2145_2.png) [@Anro](https://forum.communityhealthtoolkit.org/u/Anro)\ **Post date:** [March 24, 2026, 2:07pm UTC](https://forum.communityhealthtoolkit.org/t/form-variable-length-name-warning/5541/1 "2026-03-24T14:07:20Z")
Is there a built-in way to warn on form variable length or naming? If not, I’ve been staring at the `cht-conf` tool a little too much lately, and it feels like the perfect hammer for this. Our downstream system that pulls data from CouchDB recently ran into two issues: - we accidentally used a reserved word - due to deep nesting, some variables exceeded the allowed length It seems like a natural fit to extend the config tool. Since it already has easy access to the bind entries, it could validate whether `ref` values: - exceed the allowed length - contain reserved words This could run as part of the existing validation step. For length, we could warn once a threshold is reached and error at a defined cutoff. For a list of supplied reserved words, it probably makes sense to fail immediately. The length check might also help discourage overly deep nesting or excessively verbose variable names That said, it would be useful to have a way to explicitly ignore certain variables. Think cases where the length is known to be pushing the limits but simplifying it further would either introduce downstream issues or lose important context. As for where this configuration should live, the `
.properties` file is looking like a good spot. ---
**Author:** ![Anro](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/anro/32/2145_2.png) [@Anro](https://forum.communityhealthtoolkit.org/u/Anro)\ **Post date:** [April 9, 2026, 4:13pm UTC](https://forum.communityhealthtoolkit.org/t/form-variable-length-name-warning/5541/2 "2026-04-09T16:13:43Z")
Created issue and PR related to the above > > > \*\*Is your feature request related to a problem? Please describe.\*\* > Downstream pr…ocesses pull data from CouchDB and push it through to SQL for reporting. Variable keys are used as column names. If these names exceed the allowed column length or match a reserved word, the process breaks. Because forms contain skip logic, these problematic vars don't come through consistently, which result in intermittent interruptions. > > Additionally, a variable length warning could encourage implementers to consider their naming strategies more carefully. While brevity shouldn't come at the cost of losing context, overly verbose or unnecessarily deeply nested vars can also increase maintenance complexity and make referencing them throughout the project config more cumbersome. > > \*\*Describe the solution you'd like\*\* > Reduce downstream issues related to reserved words and variable lengths by introducing limits and restrictions and promote cleaner project config. > I propose introducing the following structure to the form properties: > \`\`\`json > { > "var\_restrictions": { > "warn\_length": \, > "error\_length": \, > "ignore\_list": \, > "reserved\_list": \ > } > } > \`\`\` > > Their functions: > \- \`warn\_length\`: Print a warning with a list of vars whose length exceeds this limit > \- \`error\_length\`: Throw an error with a list of vars whose length exceeds this limit > \- \`ignore\_list\`: Exclude specified entries from either warning or error checks > \- \`reserved\_list\`: Throw an error, with list of relevant items, if any reserved entries match form variables. > > \*\*Describe alternatives you've considered\*\* > NA > > \*\*Additional context\*\* > Forum discussion: > https://forum.communityhealthtoolkit.org/t/form-variable-length-name-warning/5541 > > > \# Description > > Performs validation checks against form variables as configured… through the related \`\.properties.json\` file. > > The proposed structure: > \`\`\`json > { > "var\_restrictions": { > "warn\_length": \, > "error\_length": \, > "ignore\_list": \, > "reserved\_list": \ > } > } > \`\`\` > > Their functions: > \- \`warn\_length\`: Print a warning with a list of vars whose length exceeds this limit > \- \`error\_length\`: Throw an error with a list of vars whose length exceeds this limit > \- \`ignore\_list\`: Exclude specified entries from either warning or error checks > \- \`reserved\_list\`: Throw an error, with list of relevant items, if any reserved entries match form variables. > > The feature also includes validation to guard against misconfiguration and surfaces these issues to the implementer. These include throwing an error if: > \- the \`warn\_length\` or \`error\_length\` contains any value other than a positive integer > \- the \`warn\_length\` and \`error\_length\` are the same > \- the \`ignore\_list\` or \`reserved\_list\` contain invalid values > \- there's any overlap between the \`ignore\_list\` and \`reserverd\_list\` > > Issue: \[804\](https://github.com/medic/cht-conf/issues/804) > > \# Code review items > > \- Readable: Concise, well named, follows the \[style guide\](https://docs.communityhealthtoolkit.org/contribute/code/style-guide/), documented if necessary. > \- Documented: Configuration and user documentation on \[cht-docs\](https://github.com/medic/cht-docs/) > \- Tested: Unit and/or integration tests where appropriate > \- Backwards compatible: Works with existing data and configuration. Any breaking changes documented in the release notes. > > \# License > > The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.