Do you really need short names in your data contract?

As a software developer, I have seen many people doing this kind of thing very frequently, with the purpose to reduce their data transfer.

[DataContract(Name = "Z")]
public class User
{
    [DataMember(Name = "A", EmitDefaultValue = false)]
    public int UserName{ get; set; }

    [DataMember(Name = "B", EmitDefaultValue = false)]
    public int Address{ get; set; }
}

So, maybe these shortcuts

Name = "Z" , Name = "A"

can give you a little advantage in terms of bandwidth reduction, but mostly it doesn’t worth it. You have to convert it back in full names to simplify your program experience. After all, it’s hard to understand what all these A, B, Z mean.

So, why are people still doing this? I think they just forget that simple compressing eliminates almost all other work they do when converting from UserName to A.

Let’s do a simple experiment. Using data from https://petstore.swagger.io/#/pet/findPetsByStatus public API, we created 4 types of files:

Initial.json , with data from API.

Initial.json

Shortnamed.json, the same as above, but category -> CT and so on.

Shortnamed.json

And 2 zip files, Initial.zip and Shortnamed.zip, which have been created by compressing initial files.

The results are presented in a table, where we compared files with different size:

Corporation of the files sizes reduction

In the “Size reduction, without using shortnames” column you can see how much reduction in size between Initial.json and Initial.zip. And in the “Size reduction with using shortnames” column you can see a reduction between Initial.json and Shortnamed.zip, where the last one was created through the following process: Initial.json -> Shortnamed.json -> Shortnamed.zip.

As you can see, the maximum benefit of using short names technic is only -0.14%, which is obviously doesn’t make any difference for a general case.

As a conclusion, don’t use short names technique until you proved it’s usefulness.