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
---
_______________________________________________
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/048a01d30635$ce9ac840$6bd058c0$@tpcqpc.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.
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.
--
Ted Roche
Ted Roche & Associates, LLC
_______________________________________________
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/CACW6n4sB6pB5DhUiTHwf98zpe-bPaKaAm_my3v6mqr7u5hYydg@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.
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
_______________________________________________
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/10ED7489-ACE7-4D2B-A88C-84633B853AEA@leafe.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.
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]
_______________________________________________
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/CAJidMYL6EKsxbC06SsA8Cr5uMtdt-9jrEa+Ccq+gGkHKAEuPUw@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.
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
_______________________________________________
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/C853EB88-D251-4E0B-B35C-34D8675DED83@leafe.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.
Author: mbsoftwaresolutions@mbsoftwaresolutions.com
Posted: 2017-07-26 13:43:20 Link
On 2017-07-26 14:00, Ed Leafe wrote:
> "Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live.”
LMAO!!!!!! This has to be one of the funniest things I've ever read on
ProFox. :D
_______________________________________________
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/3c262db236626a684d30e1c9c2ebc479@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.
Author: mbsoftwaresolutions@mbsoftwaresolutions.com
Posted: 2017-07-26 13:55:49 Link
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?
_______________________________________________
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/447f1d37cae95941a0a674fdd9a33d39@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.
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]
_______________________________________________
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/066001d30648$2cb3f700$861be500$@tpcqpc.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.
In Fox I do scope, type, name in camel case.
So
lcTaxCode
lnTaxRate
llFlag
gcApplicationName
goLogger
...and so forth.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
On Wed, 26 Jul 2017, at 06:37 PM, 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.
>
>
>
> 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]
_______________________________________________
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/1501101906.1715488.1053692264.0C677373@webmail.messagingengine.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.
+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.
>
>
>
_______________________________________________
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/98879978-C976-4280-98AE-B9ED02A3CA52@jbweller.force9.co.uk
** 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.