Interpreted QML nomenclature

lawrence.emke

Well I just ran into a collision with the name of a function I wanted to define. I assumed (ass of u and me), that the javascript engine in QML is a stripped down version (It does not support the "this" variable as the class instance) therefor I assumed it does not functionally support any of the class attributes; namely the use of the "constructor" and "destructor" routines (except within the C++ environment). I was wrong. My guess! they DO have special meanings and are apart of the javascript interpreted environment.

This brings up problem of naming things (functions and properties). QML is an interpreted environment. So the Qt system identifier names mix in with the application developers choice for identifier names.

The problem occurs when both system users (owners and clients) choose the same name. This can lead to unexpected results.

To prevent this problem in the future, I want to use a naming rule to avoid this situation. I would like to choose the "_" as a leading character for all properties that I define within a qml document. And use the "$" as the leading character for all function definitions that I create.

Is this a good idea? What other ways have other persons used and why?

fcarney

Use longer names that are descriptive:
this_pointer_to_object

I would avoid leading underscore outside of any QML use cases. I think QML uses them in places that are considered private. Not 100% sure on that. I would also not use leading underscore in C++ at all. C++ specifically reserves them for special cases.

In my QML naming I do this:

ListView {
  id: scanned_items_listview
  delegate: Item {
    id: scanned_items_listview_delegate
  }
}

Now for variables in javascript it is somewhat less critical because the names only exist in the script itself (except outside resources). In that case I would avoid any and all reserved symbols that javascript uses (even for the latest version of JS). That way if the v8 engine gets updated to a newer JS version then you won't conflict with those newer symbols. For JS names being more descriptive is far less likely for naming collisions. I also avoid simple words like "object". If I need a quick object var I just do: var obj. But if I need to differentiate I will do nobj (new object). Again, this is because the scope of the variables in the JS is much smaller than the scope of a QML Item for instance.