Naming

General naming principles that apply before any language or platform convention

Id general-naming Applies to any Status active Enforceable needs judgement Tags naming

Consistent, predictable and clear naming standards set us up for maintainable, secure, testable and easier-to-learn codebases.

Clear and tidy code makes it easier to catch issues, onboard and collaborate with coworkers, unlock our potential to scale and achieve the greatest possible quality.

While we recognize Newfold Labs codebases have often come from legacy codebases with some necessary compromises to these standards, they should be followed in all new codebases.

We have naming standards for:

General principles

Avoid inappropriate, expired and hurtful language

Strive for modern, inclusive and professional language.

If you have questions, please reach out to your manager or the Newfold Labs team.

Jargon and data types belong in documentation

Technical jargon, description of mechanics and data types most often belong in inline documentation and README files, not in class names, function names, variable names or file names. If a name feels like it’s describing mechanics or technical minutiae instead of business purpose, it can likely be improved.

Names never exist in a vacuum

Consider the names of adjacent code and products within the organization and greater ecosystem (whether they’re “well-named” or not). Names that are too similar are a tripping hazard and confusion point.

Keep in mind not only what is currently named, but what could come in the future.

Aim for parallel language construction

Contact and About, or Contact Us and About Us. Please don’t mix and match.

Also maintain nomenclature. Don’t call the same feature “options”, “tools” and “preferences” in different places across an application interface, codebase and documentation. Some of this is inevitable over time, but please strive to keep API endpoints, code, interface strings and documentation in sync.

Use appropriate pairs

Don’t intermix words like start and end. Words have natural pairs.

Avoid unnecessary truncation

Visually parsing abbreviations burns daylight and makes code less readable. We’re no longer in a time where we need to conserve characters due to memory limits.

With a few notable exceptions like ID for identifier, JS for JavaScript, and common ecosystem shorthand like ${thing}_args in WordPress, avoid excessive truncation. This aids adoption across skill levels and languages, and makes code more readable.

Avoid redundancy

Calling a file Admin_Page.php when it’s inside a folder called /admin creates redundancy both in file path and PHP namespace:

In this case, the redundancy adds noise to process instead of beneficial clarity.

Avoid oversimplifying

While at face value wp-module-cache is fairly simple and a decent name, it can be improved. It’s not very clear exactly what the codebase does. File caching? Object caching? Fragment caching? Engineers know what caching is, but others may not.

While wp-module-object-cache is more specific, consider the broader picture:

Would wp-module-performance be better? It’s broad like wp-module-cache, but talking about “the performance module” is something any stakeholder can understand. There can be specific files for each type of caching within the module.

Far from a hard rule, but a helpful framework

Spell proper nouns (brand names and product names) correctly

Always check a company or product site for the proper spelling and casing.

❌ Common mistakes ✅ Correct use
Wordpress WordPress
JetPack Jetpack
Webpack webpack
NewFold Newfold
BlueHost Bluehost
NPM npm
Javascript JavaScript
GMail Gmail