Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Java

Brendon Butler
Brendon Butler
4,254 Points
Posted by Brendon Butler
Brendon Butler
4,254 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

jesdavpet
jesdavpet
21,489 Points

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,254 Points
Brendon Butler
Brendon Butler
4,254 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.