As the author of the infamous Dim Session As Session = Session line, I can confidently say this is a bad idea. While it technically works, the main thing it does is reduce code clarity.
Var thing1 as color
Var thing2 as string
var thing3 as integer
//cant look at a row that says something = thing1. and know what its doing
//whereas
Var colThing1 as color
Var strThing2 as string
Var intThing3 as integer
I personally find that annoying. I’d rather do something like
BreadLength As Integer
BreadFlavor As String
BreadAge As Interval
This way all my related values sort together. Unless I’m using variants, the compiler checks types for me, so I don’t really need the type in the name.
Oddly, thats what I do, rather than what I said…
Hungarian is a hangover from my indentured C coding days.
I guess the point we are all making is avoid generic terms like text, color, string, int. because firstly it IS confusing, secondly it may cause odd compiler issues and thirdly, you never know when it will become an issue in a future build.
The day Xojo adds BreadLength to the language will be a long time coming.
thats why key words dim,var,as,new have a meaning for the compiler.
I guess the point we are all making is avoid generic terms like text, color, string, int.
yes frequently i can not use a variable name because its disallowed.
i not like prefix or suffix or hungarian notation for some of the “conflict” names.
a bad habit is to use german words instead
i discover long ago never to use the variable backgroundcolor or property or Notes.
that is why these days, i remember to use ABCNotes or something like that.
To be clear: I do not use this construct internally.
However, I do not consider the designation of a property like Car.Color to be wrong or even “poor programming”. It is just a matter of principle. After all, it is now possible to name things like CustomEditor.Text again, even though the Text data type is still present (albeit deprecated).
I’d argue your example is still a bad one. It paints you into a corner. It should be Car.PaintColor or Car.ExteriorColor. Because what about the upholstery? Just calling it color isn’t descriptive enough at best, or at worst means something needs to change later when additional color properties are added.
Last year, I made the exercise to use French variable names in one of my projects, mainly to check if it was possible and maintainable.
I discovered Xojo actually accepts accented characters, and, as an extend, glyphs for variable names.
This was actually a fun experience. And, of course, I didn’t have to watch out for reserved names.
So, for example, you can change this:
Var ThisPhoneIsWaterProof As Boolean
to
Var As Boolean
I agree. The compiler should be able to disambiguate based on position alone. Additionally, I would like to see “Text” and other keywords not colored when they are in the variable/property name position.
Although it can be argued that “Color” is not specific enough for programers as a property or variable name, that is besides the point. (I mean this part kindly, we name variable x,y,z,i,g,g1,g2,iiiiii frequently. And it’s my code, not yours.)
I would love to see a day when Xojo had a case sensitive variant as of the language available. I know that will never happen. Regardless, ‘color’ should be allowed as a property name unless it can be demonstrated that the compiler truly can’t disambiguate it.
As Boolean