[Interest] QML property lint suggestion

Roland Hughes roland at logikalsolutions.com
Sun Feb 16 21:17:10 CET 2020


On 2/16/20 5:00 AM, Jason H wrote:
> I'm here watching Ulf's QtWS19 QML talk and had a thought...
> I might be dumb or crazy (either are equally likely) but, the other day I added a property called 'data' and completely broke my application. It was to store data I received. However QML also declares a property 'data' which is essential to Qt. But I never got an error or warning. So my suggestion is to have some warning (or error?) like "declared property 'data' shadows an existing property"
>
> I think some talk of naming an essential-to-QML property as generically as 'data' is also worth a discussion. Naming it 'data' doesn't really describe what it is for, which is holding the children, all the children. The problem with that, is as it currently stands, the property 'children' is used to store only visual children, so I would suggest to rename that 'visualChildren', or 'childItems'. Next for the non-visual children, aka 'resources' (equally poorly named, because Qt has a 'resource' system), they should be in 'childObjects' or 'nonvisualChildren'. (But definitely not 'invisibleChildren', because is that visible=false or opacity==0 property thing?)

Now that it has been about a day and you can probably smile about it I 
can pick at the scab. <Grin>

What were you doing declaring a variable named "data"? You know better 
my friend. <Very Big Grin>

I understand what you are asking for, you want QtCreator to be able to 
do something along the lines of what it does for C++ code. It amazes me 
how the Great Bad Old Days keep repeating themselves. Creator is now 
caught up to, perhaps slightly ahead of the Rational Systems Instant-C 
product circa 1984.

http://www.softwarepreservation.org/projects/interactive_c/bib/Vose-1984.pdf
http://vetusware.com/download/INSTANT-C%20VER%202.00/?id=10724

The content of the Byte article in the PDF actually had it wrong. The 
big benefit wasn't to students. It would do much like QtCreator does for 
C++ today. "Interpret/JIT" your code while you typed and let you know 
you were using a class member variable which wasn't declared or a 
method/function which didn't have a prototype, etc. It's been a long 
time so I don't remember all it could do on an EGA monitor. In the Great 
Bad Old Days we would pay $300-$500 for an editor that could do 
something like that. Admittedly I never understood why anyone paid that 
for Brief https://en.wikipedia.org/wiki/Brief_(text_editor) yet I paid 
it for SlickEdit which was just another Brief. https://www.slickedit.com/

What can you really expect from something which is insecure and not type 
safe? The insecure thing happens from at least 2 points of entry. The 
first is a programmer cannot control the life of a variable. As others 
have mentioned in here even assigning a new value to the variable one 
uses to receive a password doesn't erase the password from memory. The 
second comes from the JavaScript code being bundled into the binary you 
ship without so much as a Base26/64 mangling. I actually spoke in the 
past month to a non-client that was coding trade-secret algorithms in 
the OpenSource Qt version using JavaScript who was completely unaware of 
this. To get their algorithms you don't have to reverse engineer the 
code, just open the binary in a text editor, read the JavaScript, type 
it in C++ and compile it. Your version should even run faster.

In the Great Bad Old Days, prior to namespaces, we had to rely on warts. 
Here is a snippet of a program from the very first book I wrote for a 
publisher.

int        attach_inv_database( DBFoxPro& inv_dbf, int o_mode)
{

     char    *dbf_name    = "INV.DBF";
     char    *idx_name    = "INV.CDX";
     int        x;
     int        c_mode;
     char    error_str [80];

     x    = inv_dbf.UseTable( dbf_name, o_mode);

     if ( x != DBSUCCESS)
     {
         inv_dbf.CloseAll();

         DBFIELD inv_flds [] = {
             { "ITEMNUM",    'C',    25,    0},
             { "DESC",        'C',    60, 0},
             { "ONHAND",        'N',    8,    2},
             { "OUNITM",        'C',    7,    0},
             { "SCHED",        'N',    8,    2},
             { "SDATE",        'D',    8,    0},
             { "SUNITM",        'C',    7,    0},
             { "",              ' ',     0,     0}};

         c_mode    = DB_READWRITE | DB_EXCLUSIVE | DB_FLUSHED |
                   DB_AUTOLOCKS;

         x = inv_dbf.CreateTable( dbf_name,
                             inv_flds,
                             c_mode);

         if ( x != DBSUCCESS)
         {
             sprintf( error_str, "Error %d creating table", x);
             ls_error_msg( error_str);
             return x;
         }

The code is using the Greenleaf Database Library and it is from back in 
that era. Greenleaf had a lot of libraries so their warts were really 
good. They had test programs which used all of their libraries so one 
could be certain you wouldn't suffer collision. Everything for the 
database library was warted with "DB". Every #define and every global 
variable had the wart. One just had to avoid using DB as a personal wart.

Some shops today still use the class member variable wart of "m_" but 
there was a large cultural rebellion against warts. In large part it was 
because Microsoft took it too far.

https://docs.microsoft.com/en-us/windows/win32/stg/coding-style-conventions

=====
Prefix combination     Description
pszMyString     A pointer to a string.
m_pszMyString     A pointer to a string that is a data member of a class.
=====

For the strings it wasn't so bad, but they also had i for Integer, l for 
long, n for Short int, etc. When the data type had to increase in size, 
globally changing the name was something often not done.

I can concur with you though. Every property created and used by the 
library itself, given the lack of control a developer has in the 
QML/JavaScript world, should be warted with "Q_" to avoid collisions. 
The fact the "_" tends to violate most shop naming standards helps 
ensure it will avoid collision.

History will once again repeat itself.

http://www.c4learn.com/c-programming/c-variable-nameing-rules/

=====

Do not use underscore as first character to avoid confusion between 
System Variable & user defined variables because many system variables 
starts with undescore

=====

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog



More information about the Interest mailing list