What's the standard naming convention for a property's backing field?

Question

Background

I'm wanting to follow the most commonly-practised naming conventions for TypeScript. I've noticed that the official website shows code examples featuring Pascal-case for types and modules and camel-case for just about everything else.

Example

I'm currently implementing a property that encapsulates a backing value:

class SomeClass {
    get status() {
        return statusBackingField;
    }
    set status(newValue: Status) {
        statusBackingField = newValue;
        //Do other work here
    }

    statusBackingField: Status;
}

Problem

The name of the property is status. In C#, I would normally name the property Status and the backing value status. Since the convention is to use camel-case for properties, this doesn't work. I'm not sure which convention I should use for consistency with other TypeScript code in general.

Question

Other languages, such as C# and Java, seem to have official or de facto standard conventions. Is there any such authoritative or de facto standard convention for naming backing fields in TypeScript?

Notes

For the close-voters: please note that I'm not looking for opinions. I'm looking for objective information as requested in the summarised question above.

Answer 1

There is no code convention standard for TypeScript. Since it is a superset of JavaScript, following JavaScript code conventions would probably be the correct approach. In such a case you would use an underscore-prefixed property _status. Idiomatically, this also matches the compiler’s use of an underscore-prefixed _this for compiled arrow functions and underscored-prefixed _super for superclasses.

Answer 2

In C# as well as TypeScript we use private _status. In C# the property will be Status. In TypeScript as you mentioned it is status

Answer 3

I think it's safe to say at this stage that there is no standard.

If someone can point me to an authoritative standard or evidence of a de-facto standard, then I may consider accepting their answer instead.