Standardization of "String Resources" nomenclature


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

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

Each string within the XML is compiled and associated with id as shown in the String Resources . These ids are placed in a resource files, R , as public static final variables. It is possible to assign any chave to each string , however this key is created warmly without 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 application texts, making internationalization work easier. By default the string.xml file is in the values folder and you can insert another language by creating another directory for example: values-es , which would be the Spanish language.


Is there a standardization of the nomenclature attributed to String Resources that is defined for improved understanding and clarity in coding?

asked by Viana 09.09.2016 в 15:07

3 answers


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

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

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

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

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

09.09.2016 / 15:39

I believe that an official standard does not really exist.

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

<string name="">Network error</string>
<string name="">Call failed</string>
<string name="">Map loading failed</string>

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

09.09.2016 в 15:24

As the code will already be "@ string /", identifying that it is a string, I chose to identify the strings only with the abbreviations of the objects, which already have a certain standardization in the market, followed by a name, such 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 lean and explanatory (ex: @ string / btn_play).

So, I use it to give meaningful names, without making them so long, so that I can immediately identify the type of object (or widget) in question.

In addition, "str_", in my opinion, would generate unnecessary pleonasm in the code, let's see:

@ string / str _......

I hope this contribution will help.

Good studies !!!

03.10.2018 в 16:18