Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Java

Brendon Butler
Brendon Butler
4,242 Points

'this.' prefix vs 'm' prefix vs nothing?

When I first learned how to program I would always use no prefixes at all mainly because I didn't know about 'this.' So if I had conflicting variables I would just have to change one of the variables.

Once I learned about 'this.' I continued to have conflicting variables, but I would just use 'this.' for member variables. I never really knew about using 'm' or 'I' or any other types of prefixes for naming conventions, just kind of stumbled across it when reading other's code.

My question is: Should I continue to use 'this.' for my member variables, or should I get in the habit of using the 'm' prefix?

1 Answer

Hey Brendon, for what it's worth, my personal opinion is that you should use whatever is clearest for you to write... and debug!

I think the "m" and "l" prefix convention is supposed to make it clearer for learners, when they aren't confident with variable scope yet. I haven't really seen this used outside of a learning environment myself.

In Java, "this." is a reference to the actual instance of the object... which is definitely a best practice to use, since it sounds like you understand variable scope.

But since you're thinking about it, and naming your variables descriptively -- you're already doing great! When you work on a larger project (with other programmers), there will probably be standards, or a "style guide" to follow.

Brendon Butler
Brendon Butler
4,242 Points

Wow, that's a really good way to look at it. Thank you for the input. :)

I do realize that everyone has there own ways to do things. And I think I'll stick with my own like you recommended. Just could get really messy and inconsistent with multiple people in a team or when different devs for a company work on improving a project.