+1 It's always good to know I use the same methodology as a master. :-)
John Weller 07976 393631 01380 723235 Sent from my iPhone > On 1 Aug 2017, at 08:44, Dave Crozier <[email protected]> wrote: > > Mike, > I agree with reasoning, but I have a slightly different methodology in that > all table/database variables AREN'T designated with a type prefix but all > programming variables are. This way there is never any confusion as I reckon > that the name in a table should only reflect the contents not the data type. > If you need to make the data type more obvious then include it in the name > i.e: > > Start_Date D > Is_Live L > Customer_Id C(20) > > Addressing any of these field in mainline programming then becomes trivial > and you can easily do: > > Scatter <Table> name oData > > dStart_Date = oData.Start_Date > > or declare a local/private variable lIs_Live with no fear of messing things > up with no confusion. > > Personally I am not a fan of the "M." prefix and find it unnecessary. > > Just a FWIW. > > Dave > > _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
