Standardization of "String Resources" nomenclature

Question

To support internationalization, the Android has "features" files called resource in XML, containing the texts to be displayed in the application. By default, the file /res/values/strings.xml has the texts of an Android application. Example:

<string name="str_titulo">Nome</string>

Each string within XML is compiled and associated with a id as shown in String Resources. These ids are placed in a resource files, R, as variables public static final. It is possible to assign any chave for each string, but this key is created lukewarm without a definitive standardization, for example:

• str_titulo_nome: name
• str_actionbar_titulo_nome: name
• str_toolbar_titulo_nome: name

The Android API already brings natively and even encourages the use of resources external to display the texts of the application, making easier the work of internationalization. By default the file string.xml stays in the folder values and it is possible to insert another language by creating another directory for example: values-es, which would be of the Spanish language.

Doubt

There is a standardization of the nomenclature assigned to String Resources which is defined for improved understanding and clarity in the codification?

Answer 1

As far as I know there is no standardization indicated by google.
However, you can find some "best practices" scattered in the documentation:

• Icon Names - Icon Design Guidelines, design tips.
• Folder Names - Providing Resources, Qualifier name Rules.

What is imposed is that names can only include lowercase characters a-z, numerical 0-9, underscore _ or point ..

Here, or in creating any other type of name, one must be consistent and descriptive.

I could put here the way I do, how I try to be consistent and descriptive, but, and especially when it comes to being descriptive, it depends a little on each one.

Perhaps a good source of inspiration is the class R of the SDK.

Answer 2

I believe an official standard doesn’t really exist.

I always look before starting the nomenclature, define what the purpose of the message, for example:

<string name="error.message.network">Network error</string>
<string name="error.message.call">Call failed</string>
<string name="error.message.map">Map loading failed</string>

And I separate by blocks, according to the objectives of the messages.

Answer 3

As the code already has "@string/", identifying that it is a string, I chose to identify the strings only with the abbreviations of the objects, which already present a certain standardization in the market, followed by a name, as:

• btn_play
• btn_register
• btn_save
• txt_result (txt for me usually does not position next to editable field)
• txt_title
• txt_instruction
• lbl_name (lbl is txt, but generally identifies an editable field)
• lbl_address
• lbl_zipcode etc

The code is dry and explanatory (e.g.: (@string/btn_play).

Thus, I take the opportunity to give meaningful names, without making them so long, being able to identify at once the type of object (or widget) in question.

Moreover, "str_", in my opinion, would generate unnecessary pleonasm in the code, let’s see:

@string/str_......

I hope this contribution helps.

Good studies!!!

Iomara.com.br