On 2017-08-01 03:44, Dave Crozier 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
Agree with you again! I could see myself embracing the "no prefix in the table" concept.
--Mike _______________________________________________ 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/8ba09a73ae71f14ab7655735d710b...@mbsoftwaresolutions.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.
