hi tom,
i proposed these prefixes (m_ ,s_) to the eclipse team because i had to use them and was tired of renaming the generated getters and setters.
jakob
Thomas Dudziak schrieb:
On 4/15/05, Martin Kal�n <[EMAIL PROTECTED]> wrote:
Jakob Braeuchi wrote:
yes, the m_fields were introduced by me. the company i work for uses this standard and when i first saw it, i found it totally useless. i'm an old smalltalker and was used to access all instVars by getters and setters, so i didn't care about the name of the instVar itself. in java code i found that most instVars were accessed directly, and sometimes even temVars or parameters had the same name as the instVars. so after all the m_ prefix looked quite useful, because it let's me spot the access to instVars quickly.
You are right, I didn't think about the encapsulation issue.
However, I think it is more of a Java de-facto standard to name getters and setters according to the members name. At least with IntelliJ IDEA refactoring tools you can then rename getters/setters and all callers of those automagically when you rename a memeber variable (which is not possible for "protected String m_foo;" vs "public String getFoo();").
But I don't have a huge issue with "m_" prefixes for members and will happily use whatever the majority decides on. :-)
Well I do, at least with the 'm' because it doesn't mean anything in Java as opposed to C++ where you'd also have g_ for global variables (outside of classes). Personally I use a similar naming standard (from my C++ and C# 'roots') which uses a simple underscore. In Eclipse, you can specify suffixes (e.g. 'm_' or '_') that Eclipse automatically recognizes when generating accessors and while refactoring.
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
