Short "general" views naming vs long precise views naming....

[Peter Simpson]

Hello @Cableguy,
For me I always start my views/controls with 3 letters, for example LblName (Label), TxtName (Textbox), BmpPhoto (Bitmap), ImgPhoto (Imageview), ChkPaid (CheckBox), CmbCondition (ComboBox) etc etc etc. I've always done that from the time I started VB, I think I got the 3 letter thing from a book that I once read.

Option 4: Lbl..., Txt..., Btn... etc

Off topic: For database tables and columns.
When I was learning database queries (many many many years ago) I used to do something like this, and I mean many many years ago.

SELECT <Columns>
FROM tbproddesc, tbprodpics
WHERE tbproddesc.Id = tbprodpics.ProdDesc_Id
AND `Stock Code` = 'ABC123';

Not long afterwards (still many many years ago) I changed my queries to something more like this

SELECT <Columns>
FROM proddesc
INNER JOIN prodpics
ON proddesc.Id = prodpics.ProdDesc_Id
WHERE Stock_code = 'ABC123';

Then there was this

SELECT <Columns>
FROM proddesc AS d
JOIN prodpics AS p
ON d.Id = p.ProdDesc_Id
WHERE Stock_code = 'ABC123';

Now my queries are more like this

SELECT <Columns>
FROM proddesc pd
JOIN prodpics pp
ON pd.Id = pp.ProdDesc_Id
WHERE Stock_code = 'ABC123';

The above all gives the save results, but that is progressing over the years for you lol ?

Sometimes I still prefer to use the actual table names rather than table aliases simply because personally it's faster for me to associate with table names rather than table aliases when I'm reading queries quickly. I don't have to think about table names, where sometimes I do have to stop and think about table aliases, I don't use AS anymore either. As you are all well aware one doesn't need to use INNER in my join statements as by default all joins are INNER not unless otherwise stated as a LEFT JOIN, RIGHT JOIN, OUT JOIN etc etc etc.

Anyway how did your original post go from Views/Control names to database query naming conventions lol ????????????

 

[rabbitBUSH]

Anyway how did your original post go from Views/Control names to

enthusiasm.

all of those strategies are fine until you start b4r - where memory space is limited by the arduino or esp32 or etc etc.....

 

[LucaMs]

enthusiasm.

all of those strategies are fine until you start b4r - where memory space is limited by the arduino or esp32 or etc etc.....

I don't know/have B4R, Arduino, ... but I suppose that inside those HWs you install the compiled code (binary code?) and that the length of the variable names in the source code does not affect the size of the final product. Same thing I think happens with B4A, B4J and B4i (and corresponding hw).

 

[rabbitBUSH]

the length of the variable names in the source code does not affect

Possibly, but I have saved space from the 32k available by shortening some names when the compile shows that the script is greater than the memory available.

well, that is if my memory is correct today.

 

[Alexander Stolte]

hmm, I find this spelling better than my own: xlblMyLabel, xpnlThatPanel, strTheString
I find it is more readable than:
xlbl_my_label
xpnl_that_panel
str_the_string

 

[Didier9]

The only case where I use (or keep) the short name is for static UI elements that I do not use in code, they are just graphical things that are static on the screen.
Anything I use in code has a descriptive name, sometimes Camel case, sometimes underscore-separated, sometimes both.
Of course, every rule has exceptions, but this is the rule of the house

 

[MrKim]

Most of what we do is Database stuff. Here is what we have done for 30 years and it has worked very well.
Meaningful names - usually with the View type on the END, if needed if it is not a bound field. And I really don't like underscores. Just use CAPS. I have never understood putting the Data Type/ Control Type at the beginning - primarily because so may things Auto-Fill and you have to get through the prefix before you get to a meaningful filter.
FirstNameLbl.Text = "First Name"
FirstNameTb.Text = FirstName

We have never really found adding the type to local variables useful because it is usually obvious and easy to look up. Rather we might append a useful description instead.
TableIDHold = TableID

There is one exception to the The underscore rule and I a, really glad we did it. Our software is up to over 400 tables now. 223 of those are server tables and the rest local.
ALL of the fields in our server side tables begin with a unique and meaningful 2 or 3 character prefix.
Inventory table:
Inv_PartNum
Inv_PartRev
PartMaster Table:
PM_PartNum
PM_PartRev
Purchase Order Lineitems:
POL_PoNum
POL_PartNum
POL_PartRev
When reading code we can immediately tell which table(s) we are working with. We initially bought an accounting package with source code which we merged in to our program and it did NOT do this and and it still drives me crazy. The field 'Description' can be in any one of a number of tables. With the table prefix you always know EXACTLY what you are working with. An example: Creating job records from Master records do you really want to set.
Description = Description
?
Another MAJOR plus of this is you don't need to specify the table when writing queries.
Description = Description
won't cut it in a query. You need:
Table1.Description = Table2.Description
however
T1_Description = T2_Description
works just fine.
When a field is "bound" to a View then we just use the complete field name and nothing else. That way we know that filed is always to contain ONLY that piece of data. If it is edited then that is what will be saved. If it is, for example a lookup fieled then it will have another name. Using the example above a form might have
PM_PartNum
PM_PartNumLookup
After the lookup they will both contain the same data.
When looking through the code you will know PM_PartNum gets saved, PM_PartNumLookup does not.

Some local tables have permanent data and we use the prefix rule. Some store temp data from the permanent tables. In this case we will frequently just use the the server field names. Makes it really easy to see where the data came from:
TempTable
LocalDataField1
LocalDataField2
PM_PartNum
PM_PartRev
POL_PoNum
Etc...