Dave, > Personally I am not a fan of the "M." prefix and find it unnecessary.
without the m.Prefix it is impossible to build a generic procedure / application. Regards, Koen 2017-08-01 10:25 GMT+02:00 John Weller <j...@jbweller.force9.co.uk>: > +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 <da...@flexipol.co.uk> 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 > > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com 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/cacuu1sttw9fqvny-ha4xfvrmikc_m5wpxoraq_vbg0jyomz...@mail.gmail.com ** 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.
