Question Properties - naming conventions

Not exactly sure where to post this...

I'm looking at the new Splines package and, in particular the V2.0.0. I see that a lot of the Properties that were previously available (e.g. range) have been made obsolete and replaced by equivalent Properties (e.g, Range).

Can anybody tell me the significance, other than coding standards) that make the capitalisation necessary? I have tended to use lower case for Properties and upper case for Methods but I realise that standards may vary from project to project.

I guess that I'm asking about Unity's standards but I'd also be keen to hear from others on what they prefer and what the .Net standards might be.

 

There's no significance outside of changing how to access it, although I believe a capitalized first letter suggests that whatever it is, it is public, whether it be method or property. They may have changed it to match the "popular" standards, so users can wrap their head around it easier.

 

Rivers of digital ink have been splattered all over the interwebs agonizing about naming conventions and code standards.

Conventions are great, but there are many counter-running arguments for exceptions.

I make a reasonable effort to adhere to most of them, but I certainly am no angel with it.

At the end of the day you NEED the code to be immediately readable primarily by you and your team (and your future team!!!), and secondarily by others who might need to use or help you with your code.

If you code for any length of time, you WILL encounter code that doesn't follow any guidelines. Be sure you haven't caused your brain to be brittle and fragile such that you cannot deal with a capitalized local variable, or you cannot deal with a lowercased public property.

In any case, it is more critical to regularly rename functions that have poor names than it is to get the capitalization correct. The code should just ... read.

 

My thanks to you both.

I've been coding for over 40 years and have seen languages, methodologies and standards come and go. As they say, the nice thing about standards is that there are so many to choose from. I guess I was surprised that the Unity code monkeys should have to make such a change. Any team I've led always had very clear guidelines on standards, picked up at desk audits and other QA processes.

So, in relation to my original query: nothing to see; move along please...

 

Excellent answer by Kurt-Dekker. I couldn't agree more.

As far as Unity goes, the original designers of the API didn't really show any interest in following C# guidelines. Just a few examples, nearly all public properties are lowercased, their member variables internally begin with m_, constants begin with k, all in all it smells like a certain coding culture of cpp, albeit without yoda conditionals (at least I hope so).

I still hate it that we don't have immutable structs (for example Matrix4x4 so that the compiler can pass it by reference) and that certain design principles (like disallowing implicit casting from Vector3 to Vector2) are not obeyed. Also, just through implementing IEquatable and IComparable, these value types would be 3 times faster in many situations, and hash-compatible. I've tested the premise of the last sentence, you don't need Burst compiler to make things run faster, mostly you need better written fundamentals. Yes, you can write your own libraries, but you can only use that for some niche services in your project, otherwise you make a mess out of everything.

I too follow the C# guidelines not too conservatively. The code should just read and not try to be too clever with the format, but it's more about consistency than anything else. Whether it's camelCase or PascalCase, who cares. I just want to be able to tell X from Y in a manner that doesn't exhaust my or anyone else's cognizance.

Regarding PascalCase of public properties, that's a recommended C# practice. So the question is why did they choose to turn their backs to loads of already existing APIs where the properties are lower-cased (like public fields are supposed to be)?

What bothers me more than the actual standard they choose, is switching from cosmetic standard A to cosmetic standard B. I don't get that part, why would anyone decide that's wise is beyond me.

Here are some funny names for these standards (even funnier is that I used all of them at some point in time):
jmp (or asm)
DIM (or BAS)
lowercased
Capitalized
camelCase (or lowerCamelCase)
PascalCase (or UpperCamelCase)
kebab-case (when the language allows -)
snake_case
SCREAMING_SNAKE_CASE (or MACRO_CASE)
pfxHungarian
__mangling (name mangling, usually combined with snake_case)
__dunder__ (or __magic__)
_internal (or _classMember)
m_class (a combo of pfxHungarian and _classMember)

and then there is
i
$dollar
ExtremelyLongNameThatAttemptsToDescribeEveryOntologicalCategory
CXICoreObj (you know what)
:huddled:
::colonoscopy::
xXMETALXx

 

Should also not forget that perhaps Range does not return the same value as range does all of the time, and in order to not break pre-existing code, they instead made it obsolete. While I doubt this is the case here, Unity does have a lot of "replaced" code which they don't want to remove to save older projects.

 

Perfectly reasonable by that's not the case.

No systemic redesign, no functional obsolescence, they're literally in a renaming frenzy.
Like mid-age crisis, only worse. I mean, what's wrong with introducing a hard line?
Sure you want to support the earlier code base, fine, maintain the old library for that purpose.

But how difficult it is for any early adopters to migrate their code to a newer version?
In my experience that actually feels better, like buying yourself a new car.
Not to mention that all decent IDEs support project-wide search and refactor functionalities.
But nah, let's roll for thousands of years with a very long tail of bad decision-making.
Let's make it so that the forums of the future are forever flooded with the question
"What is the purpose of range when there is Range?"
"It's obsolete since 1876, it's there for reverse compatibility."
"So if this API still works, can I do the same thing in several multiple ways? Doesn't that bloat the engine? Doesn't that potentially introduce more errors? Doesn't that increase technical debt?"
"Yes, yes, yes, and yes. But that's long-term support for ya. Good luck."

 

Thanks for your comments - very welcome.

However, it's not code in my case – I'm trying to prepare video tutorials for my students. We can't afford to buy 3rd party Assets for every seat in the labs so Unity's Splines are very welcome, yet very overdue. We're on shifting sands and I don't want to fill my videos with caveats on Property case and potential error messages. Nor do I have time to go back and reshoot videos. Splines 2.0.0 are pre-release but 1.0.1 are on the tech stream and, supposedly, moderately stable.

Were this a complex or obscure or advanced topic, I might forgive Unity but Splines are at the heart of many things from design to AI to scripted world building. I just think standards are a bit sloppy...

 

Challenge your students to pick up the core of what splines are with your current video, but then...

... tell them they have to apply it to the Bezier Solutions freebie asset store asset:

https://assetstore.unity.com/packages/tools/level-design/bezier-solution-113074

Works fairly well, easily extensible.

That will have the side benefit of forcing the students to pay more attention to you because you would be using the new correct package.

 

No need to explain. I wasn't criticizing you, but decision-making at Unity. But I can see what made you think I did.

It was a rhetorical question regarding their decision to introduce a code-breaking renaming scheme, and then leave the old remnants lying around in the codebase, practically forever.

So the rhetorical question I made, was regarding to their early adopters to whom this would be a breaking change and Unity saves them from having to migrate upgrade their code. But now you're highlighting the fact that you do, in fact, have to migrate, if you want to keep up.

Which means this decision is discouraging to frequent users and people's ability to learn, but embraces early adopters whose code is already stuck in paleontology. If that's not technical debt, I don't know what is.

What I proposed was a clean slate 'refactored' version, to cut off the old ways of doing things, and push things forward (if they really need to rename everything in the first place). We all know they will never do it for some godforsaken reason, but that's perfectly normal for a tool in development, with clear delineation between versions, and I can't really understand the logic behind this (maybe serialization?? but this only highlights an even deeper rabbit's hole).

 

You're going to have to try harder if you want to upset me. I'm very thick skinned

No criticism taken...

 

As for installing useful Assets. University IT departments have a difficult job building standard images on the Labs computers. hundreds of pieces of software with dependencies, customisations and versions. And keeping the machines clean means that the images are reloaded every night. Unfortunately, the lead time for adding a new file of any kind (including assets ) is 1 year. Yes, the images are only updated once a year. Unless I know exactly what I need for the year ahead I've lost my chance. Ho-hum...

 

There is no rule for private fields in C#, you can name them as you like, in fact I also use m_ s_ etc, I found this to be the easiest to distinguish between what fields are and what local variables are when reading.
However, I've already encountered protected fields in Unity with m_ , which would then violate naming standards.

For some time now, Unity has decided everything in "Unity" will conform to Microsoft's naming standard, everything in "UnityEngine" will keep the old standard.

 

That's an interesting topic. It saddens me that even education is conformed to such solemn and industrious standards. I had the worst education, don't get me wrong -- for me computers were out of picture, which is crazy considering we're now one of the greatest outsourcing farms in Europe per capita -- but I think what saddens me the most is that the West is not that much different, it's just coming from the opposite direction. The infamous student debt is spent on systems that wipe everything clean, like it was a chicken coop, not a place of knowledge. So you can't afford even the slightest individual contribution to the learning process unless you can face some kind of committee evaluating your cost-effectiveness from head to toe? That's just wow. In my case, we just had no people like you, nor the equipment to make this feasible, they were all either drunk, incompetent, or crazed by the corrupt institutions. Such a wild world.

I see. Okay that explains the renaming frenzy.