Is non-contiguous protobuf field numbering an anti-pattern?

Question

Is it an anti-pattern to have gaps in field numbers to aid readability?

The need being address by this idea is that metadata fields, which are "aspect" fields, can be placed in the proto file away from the main fields, and by numbering them using high numbers their position in the definition will agree with their numbering.

Consider this simplified example:

message Person {
    int32 id = 1;
    string first_name = 2;
    string last_name = 3;
    google.protobuf.Timestamp date_of_birth = 4;

    int32 version = 100;
    google.protobuf.Timestamp created = 101;
    google.protobuf.Timestamp updated = 102;
}

If adding a new (non-metadata) field, its number would follow on from the other main field numbers, and its position in the file would agree with that number, eg:

message Person {
    int32 id = 1;
    string first_name = 2;
    string last_name = 3;
    google.protobuf.Timestamp date_of_birth = 4;
    string middle_name = 5;

    int32 version = 100;
    google.protobuf.Timestamp created = 101;
    google.protobuf.Timestamp updated = 102;
}

which I feel makes the definition more readable after a field addition when adding fields in a non-breaking manor. It also keeps "business" fields uncluttered by metadata fields while maintaining the field numbering in natural sequential order, which although not required by the spec, is easier to maintain.

I couldn't find a reference doc that one shouldn't do this.

Is this an anti-pattern or just a bad idea? If so, why?

Is non-contiguous protobuf field numbering an anti-pattern?

0 Answers0