Why do most fields (class members) in Android tutorial start with `m`?

Understanding the 'm' Prefix in Android Class Members

Explore the historical context, purpose, and modern relevance of the 'm' prefix for member variables in Android development, a common convention seen in many tutorials and older codebases.

If you've spent any time looking at Android tutorials, sample code, or even the Android Open Source Project (AOSP) itself, you've likely encountered class member variables (fields) that begin with the letter m. For instance, you might see mTextView, mContext, or mHandler. This naming convention, while less prevalent in newer code, was once a very common practice and still appears frequently in existing projects. This article delves into the origins, rationale, and current status of this 'm' prefix in Android development.

The Historical Context and Rationale

The m prefix stands for 'member' and was adopted to clearly distinguish between local variables, method parameters, and class member variables. This convention originated from Google's internal coding style guidelines, particularly for Java development, and was heavily used within the Android framework itself. The primary goal was to improve code readability and reduce ambiguity, especially in methods where local variables might shadow member variables with similar names.

flowchart TD
    A[Code Readability Goal] --> B{Distinguish Variable Types}
    B --> C[Local Variables]
    B --> D[Method Parameters]
    B --> E[Class Members]
    E --> F["Prefix with 'm' (e.g., mVariable)"]
    C --> G[No Prefix]
    D --> G

Flowchart illustrating the rationale behind the 'm' prefix convention.

Consider a scenario where a method parameter has the same name as a class member. Without a distinguishing prefix, you would need to explicitly use this. to refer to the member variable, which can become verbose. The m prefix offered a visual shortcut, making it immediately clear whether you were dealing with a member variable or a local one, even without this..

public class MyActivity extends AppCompatActivity {
    private TextView mTextView;
    private String mMessage;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        mTextView = findViewById(R.id.my_text_view);
        String message = "Hello World!"; // Local variable
        mMessage = message; // Assigning local to member

        updateTextView(message);
    }

    private void updateTextView(String message) { // Method parameter
        // Without 'm' prefix, 'message' here refers to the parameter
        // To access the member, you'd need 'this.mMessage'
        mTextView.setText(message);
    }
}

Example of 'm' prefix in an Android Activity.

Modern Practices and Alternatives

While the m prefix served a valuable purpose, its usage has declined in recent years, particularly with the rise of Kotlin and more modern Java coding styles. Many developers now prefer to avoid prefixes, relying instead on IDE features, clear variable naming, and the explicit use of this. when necessary. The argument against prefixes often centers on reducing visual clutter and adhering to more 'natural' naming conventions.

In Kotlin, the this. keyword is often used explicitly for member variables when there's a naming conflict, or simply for clarity. Furthermore, Kotlin's properties often have backing fields that are not directly accessed, further reducing the need for such prefixes.

class MyKotlinActivity : AppCompatActivity() {
    private lateinit var textView: TextView
    private var message: String = ""

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        textView = findViewById(R.id.my_text_view)
        val message = "Hello Kotlin!" // Local variable
        this.message = message // Explicitly using 'this.' for member

        updateTextView(message)
    }

    private fun updateTextView(message: String) { // Method parameter
        textView.text = message
    }
}

Kotlin example demonstrating modern naming without the 'm' prefix.

When You Might Still Encounter It

Despite the shift in modern practices, you will still frequently encounter the m prefix in several scenarios:

1. Legacy Codebases: Older Android projects or parts of the Android framework itself will heavily utilize this convention.
2. Tutorials and Examples: Many older tutorials or those written by developers accustomed to the old style will continue to use it.
3. Team Conventions: Some development teams might still enforce this convention as part of their internal coding standards for consistency, especially in large, long-running projects.

Understanding its meaning is crucial for anyone working with Android, as it provides insight into the code's intent and helps navigate older codebases effectively.