I have never been a fan of expressing the data-type in the name of the var or function from VFP days on. lcCustomerName doesn't need c now does it? dDueDate if you need to read a d as date, why is it in the blasted name?
Everyone makes their own style and like art it is yours.
On Wed, Jul 26, 2017 at 12:37 PM, Paul H. Tarver paul@tpcqpc.com wrote:
I was reading a chapter on 'Meaningful Names' in the book "Clean Code" by Robert C. Martin last night and right after he made a big point of using "Intention-Revealing Names" ie: make the name of a variable, procedure or function reflect its use, he then takes the opportunity to trash the Hungarian Notation system (and by extension I suppose any similar naming convention, including the YAlan Griver convention) saying that with today's strongly typed variables, notation like this is useless and should be avoided.
Quite frankly, it hacked me off as I've spent the better part of 25 years learning and becoming disciplined enough to use the YAG naming convention as well as I could in FoxPro and I've used the same naming convention regardless of the language or its strongly typed variables because it works for me.
In my world, any roadmap or breadcrumbs I can leave myself for future maintenance and standardization is a good thing.
Thoughts?
Paul H. Tarver Tarver Program Consultants, Inc.
Email: mailto:paul@tpcqpc.com paul@tpcqpc.com
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]