the subString "m_"

Kindly

Am wondering about the sting "m_", why it doesn't appear when its stick on the left side of any argument.


thank you

 

I'm assuming you mean that when you create a public variable, everything leading up to the underbar doesn't appear, is that right? For example:

var My_Variable : String = "Why doesn't My_ appear?";

The above shows in the Inspector as only Variable. If that's what you're referring to then it's just a fact of life in that it's how Unity behaves (stripping everything leading up to and including the _ for Inspector display. There are bugs against this but for now it's something you have to live with.

 

Well, the reason for this is probably that some people like to call their member-variables m_myMemberVariableName. It's not a convention I personally like very much, but it's very widespread, so I wouldn't see this as a bug - rather as a feature.

If that's changed, it'll mean that a lot of scripts will suddenly get ugly "M_"-prefixes that don't make sense to any artist (and honestly, even programmers like myself will think this looks "weird") ;-)

In general, I think it's a good idea to read a bit into coding conventions (there's a lot of them out there ... not sure if for JavaScript, but definitely for C# and Java) - usually makes code more readable to stay with certain widespread guidelines (like camel-casing member variables, for instance ... then you don't even run into the problem with the underscore because you don't use it ;-) ).

 

At a minimum we ought to offer this as a preference so you can choose whether Unity forces capitalization and name truncation. Coding conventions are in fact good, but us forcing one in particular on Unity users isn't a solid way to go (IMO).

 

Yeah, that's a good point. You're right: An option to switch this on/off is probably the ideal solution (even though adding options is always a tricky issue ;-) ).

 

Would you like an option to enable options?

 

Hehe, no, I was actually more thinking of the devs and QA-team. Every option you add adds complexity to the implementation - and makes the process of quality assurance (including bug reporting) more complex, too. If you have a lot of options, you'll end up having to send the configuration file with the bug reports and make sure the exact same configuration is used when trying to reproduce the bug.

From the user-perspective, options are nice - but only to a certain degree. If you look at tools like Visual Studio - or for a real nightmare: Toad - you can really get lost in all the options. In Visual Studio, for instance, there's actually a few options where I switch back and forth frequently because I like both possibilities (and that does not really enhance productivity much - quite the contrary, in fact).

Obviously, adding a single option is comparatively cheap - but options have a tendency to add up quickly.

I think one of the really nice things about Unity (and the Mac) is their simplicity. A lot of things "just work" and look really nice - without me having to worry too much about the options. Because someone spent time really thinking what's useful, and what's just distracting ;-)

Right now, you have the option of using camelCaseForPublicMemberVariables to get a nice "Camel Case For Public Member Variables" - and if your coding style follows the "m_"-for-member-variables-prefixes, this also works without cluttering the property inspector (haven't tried just the "_"-prefix, which is also very common, but I guess that should also work).

 

This is incorrect. Unity will strip away m_ from any variables and turn camelCase into CamelCase.

This is part of making your scripts easy to approach from a graphic artists' perspective and as such there is no plan to change it