At 10:51 2017-07-26, Stephen Russell srussell705@gmail.com wrote:
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?
True. Why is the variable name not dDue?
I sometimes code using prefixes. Mine are only related to type. For example, I use "c" for count, "x" for index, and "s" for size. All of these will probably be some integer type.
Everyone makes their own style and like art it is yours.
And like art, it attracts critics.
[snip]
Sincerely,
Gene Wirchenko
True. Why is the variable name not dDue?
Because it could be an amount due?
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Gene Wirchenko Sent: 27 July 2017 04:08 To: profoxtech@leafe.com Subject: Re: Variable/Procedure Naming Conventions
At 10:51 2017-07-26, Stephen Russell srussell705@gmail.com wrote:
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?
True. Why is the variable name not dDue?
I sometimes code using prefixes. Mine are only related to type. For example, I use "c" for count, "x" for index, and "s" for size. All of these will probably be some integer type.
Everyone makes their own style and like art it is yours.
And like art, it attracts critics.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
I think at the end of the day, as with indenting and brackets in the C-derived languages, you should pick your own style and be consistent, and if you're in a team with a published house style then you should use that.
On 2017-07-27 04:35, Alan Bourke wrote:
I think at the end of the day, as with indenting and brackets in the C-derived languages, you should pick your own style and be consistent, and if you're in a team with a published house style then you should use that.
+1
-
Alan Bourke -
Gene Wirchenko -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Paul Newton