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 ---
On Wed, Jul 26, 2017 at 1:37 PM, Paul H. Tarver paul@tpcqpc.com wrote:
saying that with today's strongly typed variables, notation like this is useless and should be avoided.
Quite frankly, it hacked me off
I completely agree *if you are using a strongly-typed language* that including the type-prefix in the variable/field names is redundant. VFP is NOT strongly typed, so sometimes it's handy.
Any standard, even an arbitrary one, is better than a system that mixes Hungarian with camelCase with the next cool naming scheme.
On Jul 26, 2017, at 12:45 PM, Ted Roche tedroche@gmail.com wrote:
I completely agree *if you are using a strongly-typed language* that including the type-prefix in the variable/field names is redundant. VFP is NOT strongly typed, so sometimes it's handy.
While 25 years ago I adopted the Hungarian notation that was promoted in Codebook, when I left the Fox world I found that no one else used it. My early Python code used it, and reading it now it seems kind of silly. Using a clear variable name is all that I need now.
Also, “strongly-typed language” is not the same as statically-typed, which is probably what the author meant. Python is strongly-typed, meaning that a statement like:
x = 1 + “0”
will raise an exception.
-- Ed Leafe
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]
On Jul 26, 2017, at 12:51 PM, Stephen Russell srussell705@gmail.com wrote:
Everyone makes their own style and like art it is yours.
I wouldn’t go that far. If you’ve seen my art, you wouldn’t want to read code that looked like that. :)
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
-- Ed Leafe
On 2017-07-26 13:37, Paul H. Tarver 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.
What is the YAG naming convention? lcName, ldDue, or is it more CamelCase like DateDue?
The way I understand it, it is more like lnLoopCnt, tnPara, laDropList, etc.
At least that's what I've been trying to be disciplined to do because it helps ME maintain and support my own code. It's often a case of helping me remember what I was trying to do years down the road. I'm a firm believer in finding a style that works for you and then sticking to it in everything you write. Maybe that is outdated, but that's just me.
I also try not to duplicate like "ldDueDate", or "lnInvNum".
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Wednesday, July 26, 2017 1:56 PM To: profoxtech@leafe.com Subject: Re: Variable/Procedure Naming Conventions
On 2017-07-26 13:37, Paul H. Tarver 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.
What is the YAG naming convention? lcName, ldDue, or is it more CamelCase like DateDue?
[excessive quoting removed by server]
On Wed, Jul 26, 2017 at 2:55 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
What is the YAG naming convention? lcName, ldDue, or is it more CamelCase like DateDue?
http://fox.wikis.com/wc.dll?Wiki~NamingConventionsVariables
https://msdn.microsoft.com/en-us/library/4k6dthew(v=vs.71).aspx
On 2017-07-26 19:13, Ted Roche wrote:
On Wed, Jul 26, 2017 at 2:55 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
What is the YAG naming convention? lcName, ldDue, or is it more CamelCase like DateDue?
http://fox.wikis.com/wc.dll?Wiki~NamingConventionsVariables
https://msdn.microsoft.com/en-us/library/4k6dthew(v=vs.71).aspx
Thanks, Ted
In Fox I do scope, type, name in camel case.
So lcTaxCode lnTaxRate llFlag gcApplicationName goLogger
...and so forth.
+1
John Weller 01380 723235 079763 93631 Sent from my iPad
On 26 Jul 2017, at 21:45, Alan Bourke alanpbourke@fastmail.fm wrote:
In Fox I do scope, type, name in camel case.
So lcTaxCode lnTaxRate llFlag gcApplicationName goLogger
...and so forth.
+1 On 26-Jul-17 10:03 PM, John Weller wrote:
+1
John Weller 01380 723235 079763 93631 Sent from my iPad
On 26 Jul 2017, at 21:45, Alan Bourke alanpbourke@fastmail.fm wrote:
In Fox I do scope, type, name in camel case.
So lcTaxCode lnTaxRate llFlag gcApplicationName goLogger
...and so forth.
[excessive quoting removed by server]
-
Alan Bourke -
AndyHC -
Ed Leafe -
John Weller -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Paul H. Tarver -
Stephen Russell -
Ted Roche