Naming Functions in HTML/OS

A Practical Convention

In many programming languages, we have the ability to define functions with optional or variable numbers of parameters. Flexible function calls are a staple of expressive code.

In HTML/OS that’s not an option?

Recently, while working on a project, I ran into exactly that limitation: no support for variable arguments. We only have plain, fixed parameter functions.

So I created a naming convention to make things readable, maintainable, and intuitive.

---

The Convention

The idea is simple: prefix the function name with pN, where N is the number of parameters the function accepts.

Here’s how it looks in action:

    p0message()              // Zero-parameter version
    p1message(message)       // One-parameter version
    p2message(message, code) // Two-parameter version


    message(message)         // Most common usage
                                short for p1message

By encoding the number of parameters in the function name itself, it keeps everything readable and searchable.

---

Why This Works

This naming pattern has a few key advantages:

Clarity

From the name alone, you know exactly how many parameters the function expects. That’s a huge win for readability, especially in constrained environments.

Consistency

When you adopt this convention project-wide, you get predictable naming. If you see p2connect, you know it expects two parameters. If you only have one, you don’t call it — you call p1connect.

Fallbacks and Defaults

The "shorthand" version (in this case, message(message) can act as the default/common usage. You can decide on a per-function basis which version is most used and give it the cleanest name.

Searching your codebase

By placing the fnN at the front of the name searches for your function in your codebase (i.e. searching "message(") will return all invocations of the variations of the function.

---

Real-World Example

Say you're building a logging system. You might have:

    p0log()                   // Log a default message
    p1log(message)            // Log a custom message
    p2log(message, severity)  // Log with severity level
    log(message)              // Alias for Fn1log

The result is clean, intuitive, and scalable.

---

When You Should Consider This

Use this convention if you want to make your function calls explicit and self-documenting

---

Final Thoughts

This isn't a pattern you'll find in more popular programming languages — and that's the point. It’s a pragmatic solution to a very specific constraint. And in programming, pragmatism beats purity every time.

So if you're working in HTML/OS and need a clean way to handle different function signatures, give the FnN pattern a try.

It just might be the simplest fix you'll never need to debug.