PDA

View Full Version : Naming Consistency



Garret Mott
13-Mar-2005, 08:01 PM
Hi All -

I started this topic in the Ver. 11 Alpha NG kind of by accident. I said I
would post it here, so here it is.

DF & VDF have been around a long time. The language has matured greatly
over this time, but not without growing pains. To me, one of the biggest
issues is lack of consistency in naming of properties, events & methods.

Various posts in various places have talked about this, but I thought it
might be good to get some discussion under a new thread.

One of the things that prompts me to do so is a reply I received from John
Tuohy (in the Ver. 11 Alpha NG):
<JT>
This is a big topic and this is probably not the best place to dig into it
but here is the short answer. We have a lot of history in our naming
conventions. They've been around for a lot of years and they've changed a
lot over the years (and not always in the most consistent fashion). We can't
change old names and there is never a single rule we can apply to creating
new names. Sometimes we use older style names to create consistency with
existing messages, sometimes we use whatever we happens to be our current
naming convention and sometimes we use some kind of mix.
</JT>

While this all makes sense, I'm thinking that at some point it needs to
change. (DAW- don't you just love your customers telling you what to do?;-)
Many of us have "grown up" with DF, so we've seen the changes occur
gradually. Now picture coming into the language cold. Wow! What a
learning curve.

Think of this when looking through help in a new language:

Properties: TypeFace & psTypeFace, FontSize & piFontSize for example. In
general, why do some have the "p*" prefix & some not? Why Font & TypeFace?

Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
Shouldn't there be one function that has properties to set it to what you
want? Message_Box comes closest, but why all the others? How about
InputBox, while we're at it? OK, now - which are procedures & which are
functions? Do I "Get" this one or "Send" it? Then names: I think it was
Wil van Antwerpen who brought up the "Do" prefix for methods concept.
Whatever the convention, consistency would be best

Events: In dbGrid you have Column_Combo_Fill_List & Combo_Edit_Changed. Why
is one preceded by "Column_" & the other not? Why does Column_Shadow_State
work differently than Item_Shadow_State?

These are just a few examples, and probably not the least consistent. I
don't know what can be done for properties (except maybe a bunch of
"#Replace"s - oops - "Define"s?), but it seems to me that Events & Methods
could be cleaned up with wrappers:

Procedure Column_Combo_Edit_Changed integer iItem
Send Combo_Edit_Changed iItem
End_Procedure

Yes, there's some overhead, but would it make that big a difference? Maybe
I'm nuts, and probably many folks have better solutions/thoughts, but I
wanted to get this out here.

Thanks for listening,

Garret

Garret Mott
14-Mar-2005, 08:16 AM
And one more thing: underscores:

CurrentRowTextColor
Column_Shadow_State

I'd love to see them consistent as well. OK - I'd really like all the
underscores to go away, since my feeling is that this is a holdover from
"all caps" programming days. Others may (probably do?) disagree.

Garret

"Garret Mott" <garret@automatesoftware.com> wrote in message
news:RQQMfFDKFHA.7024@dacmail.dataaccess.com...
> Hi All -
>
> I started this topic in the Ver. 11 Alpha NG kind of by accident. I said
> I would post it here, so here it is.
>
> DF & VDF have been around a long time. The language has matured greatly
> over this time, but not without growing pains. To me, one of the biggest
> issues is lack of consistency in naming of properties, events & methods.
>
> Various posts in various places have talked about this, but I thought it
> might be good to get some discussion under a new thread.
>
> One of the things that prompts me to do so is a reply I received from John
> Tuohy (in the Ver. 11 Alpha NG):
> <JT>
> This is a big topic and this is probably not the best place to dig into it
> but here is the short answer. We have a lot of history in our naming
> conventions. They've been around for a lot of years and they've changed a
> lot over the years (and not always in the most consistent fashion). We
> can't change old names and there is never a single rule we can apply to
> creating new names. Sometimes we use older style names to create
> consistency with existing messages, sometimes we use whatever we happens
> to be our current naming convention and sometimes we use some kind of mix.
> </JT>
>
> While this all makes sense, I'm thinking that at some point it needs to
> change. (DAW- don't you just love your customers telling you what to
> do?;-) Many of us have "grown up" with DF, so we've seen the changes occur
> gradually. Now picture coming into the language cold. Wow! What a
> learning curve.
>
> Think of this when looking through help in a new language:
>
> Properties: TypeFace & psTypeFace, FontSize & piFontSize for example. In
> general, why do some have the "p*" prefix & some not? Why Font &
> TypeFace?
>
> Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
> Shouldn't there be one function that has properties to set it to what you
> want? Message_Box comes closest, but why all the others? How about
> InputBox, while we're at it? OK, now - which are procedures & which are
> functions? Do I "Get" this one or "Send" it? Then names: I think it was
> Wil van Antwerpen who brought up the "Do" prefix for methods concept.
> Whatever the convention, consistency would be best
>
> Events: In dbGrid you have Column_Combo_Fill_List & Combo_Edit_Changed.
> Why is one preceded by "Column_" & the other not? Why does
> Column_Shadow_State work differently than Item_Shadow_State?
>
> These are just a few examples, and probably not the least consistent. I
> don't know what can be done for properties (except maybe a bunch of
> "#Replace"s - oops - "Define"s?), but it seems to me that Events & Methods
> could be cleaned up with wrappers:
>
> Procedure Column_Combo_Edit_Changed integer iItem
> Send Combo_Edit_Changed iItem
> End_Procedure
>
> Yes, there's some overhead, but would it make that big a difference?
> Maybe I'm nuts, and probably many folks have better solutions/thoughts,
> but I wanted to get this out here.
>
> Thanks for listening,
>
> Garret
>
>

Knut Sparhell
14-Mar-2005, 08:29 AM
Garret Mott wrote:
> And one more thing: underscores:
>
> CurrentRowTextColor
> Column_Shadow_State
>
> I'd love to see them consistent as well. OK - I'd really like all the
> underscores to go away, since my feeling is that this is a holdover from
> "all caps" programming days. Others may (probably do?) disagree.

I agree. Away with all underscores and all unnecessary CAPS. Make the
old method call the new one and keep compatibility?

--
Knut Sparhell, Norway

Garret Mott
14-Mar-2005, 09:03 AM
Or would that be "Make the new one call the old one"? <g>

Whichever way - love to see it.

Garret

"Knut Sparhell" <knut@sparhell.no> wrote in message
news:DGBXknJKFHA.7472@dacmail.dataaccess.com...
> Garret Mott wrote:
>> And one more thing: underscores:
>>
>> CurrentRowTextColor
>> Column_Shadow_State
>>
>> I'd love to see them consistent as well. OK - I'd really like all the
>> underscores to go away, since my feeling is that this is a holdover from
>> "all caps" programming days. Others may (probably do?) disagree.
>
> I agree. Away with all underscores and all unnecessary CAPS. Make the old
> method call the new one and keep compatibility?
>
> --
> Knut Sparhell, Norway

Chris Spencer
15-Mar-2005, 01:29 AM
I agree. Get rid of underscores, but for backwards sake (if an issues) have
the old methods call the newer ones



Chris Spencer
TUFware Systems

"Garret Mott" <garret@automatesoftware.com> wrote in message
news:imghcgJKFHA.5816@dacmail.dataaccess.com...
> And one more thing: underscores:
>
> CurrentRowTextColor
> Column_Shadow_State
>
> I'd love to see them consistent as well. OK - I'd really like all the
> underscores to go away, since my feeling is that this is a holdover from
> "all caps" programming days. Others may (probably do?) disagree.
>
> Garret
>
> "Garret Mott" <garret@automatesoftware.com> wrote in message
> news:RQQMfFDKFHA.7024@dacmail.dataaccess.com...
>> Hi All -
>>
>> I started this topic in the Ver. 11 Alpha NG kind of by accident. I said
>> I would post it here, so here it is.
>>
>> DF & VDF have been around a long time. The language has matured greatly
>> over this time, but not without growing pains. To me, one of the biggest
>> issues is lack of consistency in naming of properties, events & methods.
>>
>> Various posts in various places have talked about this, but I thought it
>> might be good to get some discussion under a new thread.
>>
>> One of the things that prompts me to do so is a reply I received from
>> John Tuohy (in the Ver. 11 Alpha NG):
>> <JT>
>> This is a big topic and this is probably not the best place to dig into
>> it but here is the short answer. We have a lot of history in our naming
>> conventions. They've been around for a lot of years and they've changed a
>> lot over the years (and not always in the most consistent fashion). We
>> can't change old names and there is never a single rule we can apply to
>> creating new names. Sometimes we use older style names to create
>> consistency with existing messages, sometimes we use whatever we happens
>> to be our current naming convention and sometimes we use some kind of
>> mix.
>> </JT>
>>
>> While this all makes sense, I'm thinking that at some point it needs to
>> change. (DAW- don't you just love your customers telling you what to
>> do?;-) Many of us have "grown up" with DF, so we've seen the changes
>> occur gradually. Now picture coming into the language cold. Wow! What
>> a learning curve.
>>
>> Think of this when looking through help in a new language:
>>
>> Properties: TypeFace & psTypeFace, FontSize & piFontSize for example.
>> In general, why do some have the "p*" prefix & some not? Why Font &
>> TypeFace?
>>
>> Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
>> Shouldn't there be one function that has properties to set it to what you
>> want? Message_Box comes closest, but why all the others? How about
>> InputBox, while we're at it? OK, now - which are procedures & which are
>> functions? Do I "Get" this one or "Send" it? Then names: I think it
>> was Wil van Antwerpen who brought up the "Do" prefix for methods concept.
>> Whatever the convention, consistency would be best
>>
>> Events: In dbGrid you have Column_Combo_Fill_List & Combo_Edit_Changed.
>> Why is one preceded by "Column_" & the other not? Why does
>> Column_Shadow_State work differently than Item_Shadow_State?
>>
>> These are just a few examples, and probably not the least consistent. I
>> don't know what can be done for properties (except maybe a bunch of
>> "#Replace"s - oops - "Define"s?), but it seems to me that Events &
>> Methods could be cleaned up with wrappers:
>>
>> Procedure Column_Combo_Edit_Changed integer iItem
>> Send Combo_Edit_Changed iItem
>> End_Procedure
>>
>> Yes, there's some overhead, but would it make that big a difference?
>> Maybe I'm nuts, and probably many folks have better solutions/thoughts,
>> but I wanted to get this out here.
>>
>> Thanks for listening,
>>
>> Garret
>>
>>
>
>

phvwijk
15-Mar-2005, 08:19 AM
Chris,

If a move like this is done I think a compiler directive should be there to
give a warning of you use old method's.
That is something I would like to have for

Send MyMessage To MyObject

That should if I want generate a compiler error / warning
There are more cases like that.

Something like #SET_OBSOLETE_ERROR_ON


Peter H. van Wijk
X-Organize Consultancy N.V.

"Chris Spencer" <chris@tufware.com.au> wrote in message
news:G3pwocSKFHA.7472@dacmail.dataaccess.com...
>I agree. Get rid of underscores, but for backwards sake (if an issues)
>have the old methods call the newer ones
>
>
>
> Chris Spencer
> TUFware Systems
>
> "Garret Mott" <garret@automatesoftware.com> wrote in message
> news:imghcgJKFHA.5816@dacmail.dataaccess.com...
>> And one more thing: underscores:
>>
>> CurrentRowTextColor
>> Column_Shadow_State
>>
>> I'd love to see them consistent as well. OK - I'd really like all the
>> underscores to go away, since my feeling is that this is a holdover from
>> "all caps" programming days. Others may (probably do?) disagree.
>>
>> Garret
>>
>> "Garret Mott" <garret@automatesoftware.com> wrote in message
>> news:RQQMfFDKFHA.7024@dacmail.dataaccess.com...
>>> Hi All -
>>>
>>> I started this topic in the Ver. 11 Alpha NG kind of by accident. I
>>> said I would post it here, so here it is.
>>>
>>> DF & VDF have been around a long time. The language has matured greatly
>>> over this time, but not without growing pains. To me, one of the
>>> biggest issues is lack of consistency in naming of properties, events &
>>> methods.
>>>
>>> Various posts in various places have talked about this, but I thought it
>>> might be good to get some discussion under a new thread.
>>>
>>> One of the things that prompts me to do so is a reply I received from
>>> John Tuohy (in the Ver. 11 Alpha NG):
>>> <JT>
>>> This is a big topic and this is probably not the best place to dig into
>>> it but here is the short answer. We have a lot of history in our naming
>>> conventions. They've been around for a lot of years and they've changed
>>> a lot over the years (and not always in the most consistent fashion). We
>>> can't change old names and there is never a single rule we can apply to
>>> creating new names. Sometimes we use older style names to create
>>> consistency with existing messages, sometimes we use whatever we happens
>>> to be our current naming convention and sometimes we use some kind of
>>> mix.
>>> </JT>
>>>
>>> While this all makes sense, I'm thinking that at some point it needs to
>>> change. (DAW- don't you just love your customers telling you what to
>>> do?;-) Many of us have "grown up" with DF, so we've seen the changes
>>> occur gradually. Now picture coming into the language cold. Wow! What
>>> a learning curve.
>>>
>>> Think of this when looking through help in a new language:
>>>
>>> Properties: TypeFace & psTypeFace, FontSize & piFontSize for example.
>>> In general, why do some have the "p*" prefix & some not? Why Font &
>>> TypeFace?
>>>
>>> Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
>>> Shouldn't there be one function that has properties to set it to what
>>> you want? Message_Box comes closest, but why all the others? How about
>>> InputBox, while we're at it? OK, now - which are procedures & which are
>>> functions? Do I "Get" this one or "Send" it? Then names: I think it
>>> was Wil van Antwerpen who brought up the "Do" prefix for methods
>>> concept. Whatever the convention, consistency would be best
>>>
>>> Events: In dbGrid you have Column_Combo_Fill_List & Combo_Edit_Changed.
>>> Why is one preceded by "Column_" & the other not? Why does
>>> Column_Shadow_State work differently than Item_Shadow_State?
>>>
>>> These are just a few examples, and probably not the least consistent. I
>>> don't know what can be done for properties (except maybe a bunch of
>>> "#Replace"s - oops - "Define"s?), but it seems to me that Events &
>>> Methods could be cleaned up with wrappers:
>>>
>>> Procedure Column_Combo_Edit_Changed integer iItem
>>> Send Combo_Edit_Changed iItem
>>> End_Procedure
>>>
>>> Yes, there's some overhead, but would it make that big a difference?
>>> Maybe I'm nuts, and probably many folks have better solutions/thoughts,
>>> but I wanted to get this out here.
>>>
>>> Thanks for listening,
>>>
>>> Garret
>>>
>>>
>>
>>
>
>

Mark Powers
15-Mar-2005, 11:19 AM
Peter - I like this ideal also of giving warning messages.
Mark

Peter H. van Wijk wrote:
> Chris,
>
> If a move like this is done I think a compiler directive should be there to
> give a warning of you use old method's.
> That is something I would like to have for
>
> Send MyMessage To MyObject
>
> That should if I want generate a compiler error / warning
> There are more cases like that.
>
> Something like #SET_OBSOLETE_ERROR_ON
>
>
> Peter H. van Wijk
> X-Organize Consultancy N.V.
>
> "Chris Spencer" <chris@tufware.com.au> wrote in message
> news:G3pwocSKFHA.7472@dacmail.dataaccess.com...
>
>>I agree. Get rid of underscores, but for backwards sake (if an issues)
>>have the old methods call the newer ones
>>
>>
>>
>>Chris Spencer
>>TUFware Systems
>>
>>"Garret Mott" <garret@automatesoftware.com> wrote in message
>>news:imghcgJKFHA.5816@dacmail.dataaccess.com...
>>
>>>And one more thing: underscores:
>>>
>>>CurrentRowTextColor
>>>Column_Shadow_State
>>>
>>>I'd love to see them consistent as well. OK - I'd really like all the
>>>underscores to go away, since my feeling is that this is a holdover from
>>>"all caps" programming days. Others may (probably do?) disagree.
>>>
>>>Garret
>>>
>>>"Garret Mott" <garret@automatesoftware.com> wrote in message
>>>news:RQQMfFDKFHA.7024@dacmail.dataaccess.com...
>>>
>>>>Hi All -
>>>>
>>>>I started this topic in the Ver. 11 Alpha NG kind of by accident. I
>>>>said I would post it here, so here it is.
>>>>
>>>>DF & VDF have been around a long time. The language has matured greatly
>>>>over this time, but not without growing pains. To me, one of the
>>>>biggest issues is lack of consistency in naming of properties, events &
>>>>methods.
>>>>
>>>>Various posts in various places have talked about this, but I thought it
>>>>might be good to get some discussion under a new thread.
>>>>
>>>>One of the things that prompts me to do so is a reply I received from
>>>>John Tuohy (in the Ver. 11 Alpha NG):
>>>><JT>
>>>>This is a big topic and this is probably not the best place to dig into
>>>>it but here is the short answer. We have a lot of history in our naming
>>>>conventions. They've been around for a lot of years and they've changed
>>>>a lot over the years (and not always in the most consistent fashion). We
>>>>can't change old names and there is never a single rule we can apply to
>>>>creating new names. Sometimes we use older style names to create
>>>>consistency with existing messages, sometimes we use whatever we happens
>>>>to be our current naming convention and sometimes we use some kind of
>>>>mix.
>>>></JT>
>>>>
>>>>While this all makes sense, I'm thinking that at some point it needs to
>>>>change. (DAW- don't you just love your customers telling you what to
>>>>do?;-) Many of us have "grown up" with DF, so we've seen the changes
>>>>occur gradually. Now picture coming into the language cold. Wow! What
>>>>a learning curve.
>>>>
>>>>Think of this when looking through help in a new language:
>>>>
>>>>Properties: TypeFace & psTypeFace, FontSize & piFontSize for example.
>>>>In general, why do some have the "p*" prefix & some not? Why Font &
>>>>TypeFace?
>>>>
>>>>Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
>>>>Shouldn't there be one function that has properties to set it to what
>>>>you want? Message_Box comes closest, but why all the others? How about
>>>>InputBox, while we're at it? OK, now - which are procedures & which are
>>>>functions? Do I "Get" this one or "Send" it? Then names: I think it
>>>>was Wil van Antwerpen who brought up the "Do" prefix for methods
>>>>concept. Whatever the convention, consistency would be best
>>>>
>>>>Events: In dbGrid you have Column_Combo_Fill_List & Combo_Edit_Changed.
>>>>Why is one preceded by "Column_" & the other not? Why does
>>>>Column_Shadow_State work differently than Item_Shadow_State?
>>>>
>>>>These are just a few examples, and probably not the least consistent. I
>>>>don't know what can be done for properties (except maybe a bunch of
>>>>"#Replace"s - oops - "Define"s?), but it seems to me that Events &
>>>>Methods could be cleaned up with wrappers:
>>>>
>>>>Procedure Column_Combo_Edit_Changed integer iItem
>>>> Send Combo_Edit_Changed iItem
>>>>End_Procedure
>>>>
>>>>Yes, there's some overhead, but would it make that big a difference?
>>>>Maybe I'm nuts, and probably many folks have better solutions/thoughts,
>>>>but I wanted to get this out here.
>>>>
>>>>Thanks for listening,
>>>>
>>>>Garret
>>>>
>>>>
>>>
>>>
>>
>
>

Grant Harrington
15-Mar-2005, 01:02 PM
Sounds like a great idea to me. There's nothing worse than having to refer
to the help system just because you can't remember where the person who
defined the message happened to put the underscores.

Grant Harrington
Handmade Software

"Mark Powers" <markp@remacinc.com> wrote in message
news:pBAmZrXKFHA.1912@dacmail.dataaccess.com...
> Peter - I like this ideal also of giving warning messages.
> Mark
>
> Peter H. van Wijk wrote:
> > Chris,
> >
> > If a move like this is done I think a compiler directive should be there
to
> > give a warning of you use old method's.
> > That is something I would like to have for
> >
> > Send MyMessage To MyObject
> >
> > That should if I want generate a compiler error / warning
> > There are more cases like that.
> >
> > Something like #SET_OBSOLETE_ERROR_ON
> >
> >
> > Peter H. van Wijk
> > X-Organize Consultancy N.V.
> >
> > "Chris Spencer" <chris@tufware.com.au> wrote in message
> > news:G3pwocSKFHA.7472@dacmail.dataaccess.com...
> >
> >>I agree. Get rid of underscores, but for backwards sake (if an issues)
> >>have the old methods call the newer ones
> >>
> >>
> >>
> >>Chris Spencer
> >>TUFware Systems
> >>
> >>"Garret Mott" <garret@automatesoftware.com> wrote in message
> >>news:imghcgJKFHA.5816@dacmail.dataaccess.com...
> >>
> >>>And one more thing: underscores:
> >>>
> >>>CurrentRowTextColor
> >>>Column_Shadow_State
> >>>
> >>>I'd love to see them consistent as well. OK - I'd really like all the
> >>>underscores to go away, since my feeling is that this is a holdover
from
> >>>"all caps" programming days. Others may (probably do?) disagree.
> >>>
> >>>Garret
> >>>
> >>>"Garret Mott" <garret@automatesoftware.com> wrote in message
> >>>news:RQQMfFDKFHA.7024@dacmail.dataaccess.com...
> >>>
> >>>>Hi All -
> >>>>
> >>>>I started this topic in the Ver. 11 Alpha NG kind of by accident. I
> >>>>said I would post it here, so here it is.
> >>>>
> >>>>DF & VDF have been around a long time. The language has matured
greatly
> >>>>over this time, but not without growing pains. To me, one of the
> >>>>biggest issues is lack of consistency in naming of properties, events
&
> >>>>methods.
> >>>>
> >>>>Various posts in various places have talked about this, but I thought
it
> >>>>might be good to get some discussion under a new thread.
> >>>>
> >>>>One of the things that prompts me to do so is a reply I received from
> >>>>John Tuohy (in the Ver. 11 Alpha NG):
> >>>><JT>
> >>>>This is a big topic and this is probably not the best place to dig
into
> >>>>it but here is the short answer. We have a lot of history in our
naming
> >>>>conventions. They've been around for a lot of years and they've
changed
> >>>>a lot over the years (and not always in the most consistent fashion).
We
> >>>>can't change old names and there is never a single rule we can apply
to
> >>>>creating new names. Sometimes we use older style names to create
> >>>>consistency with existing messages, sometimes we use whatever we
happens
> >>>>to be our current naming convention and sometimes we use some kind of
> >>>>mix.
> >>>></JT>
> >>>>
> >>>>While this all makes sense, I'm thinking that at some point it needs
to
> >>>>change. (DAW- don't you just love your customers telling you what to
> >>>>do?;-) Many of us have "grown up" with DF, so we've seen the changes
> >>>>occur gradually. Now picture coming into the language cold. Wow!
What
> >>>>a learning curve.
> >>>>
> >>>>Think of this when looking through help in a new language:
> >>>>
> >>>>Properties: TypeFace & psTypeFace, FontSize & piFontSize for example.
> >>>>In general, why do some have the "p*" prefix & some not? Why Font &
> >>>>TypeFace?
> >>>>
> >>>>Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
> >>>>Shouldn't there be one function that has properties to set it to what
> >>>>you want? Message_Box comes closest, but why all the others? How
about
> >>>>InputBox, while we're at it? OK, now - which are procedures & which
are
> >>>>functions? Do I "Get" this one or "Send" it? Then names: I think it
> >>>>was Wil van Antwerpen who brought up the "Do" prefix for methods
> >>>>concept. Whatever the convention, consistency would be best
> >>>>
> >>>>Events: In dbGrid you have Column_Combo_Fill_List &
Combo_Edit_Changed.
> >>>>Why is one preceded by "Column_" & the other not? Why does
> >>>>Column_Shadow_State work differently than Item_Shadow_State?
> >>>>
> >>>>These are just a few examples, and probably not the least consistent.
I
> >>>>don't know what can be done for properties (except maybe a bunch of
> >>>>"#Replace"s - oops - "Define"s?), but it seems to me that Events &
> >>>>Methods could be cleaned up with wrappers:
> >>>>
> >>>>Procedure Column_Combo_Edit_Changed integer iItem
> >>>> Send Combo_Edit_Changed iItem
> >>>>End_Procedure
> >>>>
> >>>>Yes, there's some overhead, but would it make that big a difference?
> >>>>Maybe I'm nuts, and probably many folks have better
solutions/thoughts,
> >>>>but I wanted to get this out here.
> >>>>
> >>>>Thanks for listening,
> >>>>
> >>>>Garret
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >

Michel Boisvert
16-Mar-2005, 08:16 AM
Hi,

I agree to you all and would like consistency not to disturb too much what
we have done so far.. Looking back, I must say than having underscores in
function name make it easier to read ..

How about changing the compiler to get rid of underscores before compiling,
that way,

That_Function would do the same as ThatFunction and anybody will be happy.
You could use any combination of underscores or not, just how you fell
today!

Another way would be to have a series of Replace statements used to replace
function names before they compile.

--
Salutations,

Michel Boisvert, dir technique (Michel.Boisvert@ipso.ca)

Ipso Systèmes Stratégiques Inc,

JimNC9
16-Mar-2005, 09:59 AM
Yes, I have to do the same. Consistency would be a big help.

Jim /*

WebApp Hosting
http://www.advanceddesignsinc.com/Web%20Hosting.htm


"Grant Harrington" <grant.harrington@handmade.co.nz> wrote in message
news:aLVpVlYKFHA.1912@dacmail.dataaccess.com...
> Sounds like a great idea to me. There's nothing worse than having to
> refer
> to the help system just because you can't remember where the person who
> defined the message happened to put the underscores.
>
> Grant Harrington
> Handmade Software
>
> "Mark Powers" <markp@remacinc.com> wrote in message
> news:pBAmZrXKFHA.1912@dacmail.dataaccess.com...
>> Peter - I like this ideal also of giving warning messages.
>> Mark
>>
>> Peter H. van Wijk wrote:
>> > Chris,
>> >
>> > If a move like this is done I think a compiler directive should be
>> > there
> to
>> > give a warning of you use old method's.
>> > That is something I would like to have for
>> >
>> > Send MyMessage To MyObject
>> >
>> > That should if I want generate a compiler error / warning
>> > There are more cases like that.
>> >
>> > Something like #SET_OBSOLETE_ERROR_ON
>> >
>> >
>> > Peter H. van Wijk
>> > X-Organize Consultancy N.V.
>> >
>> > "Chris Spencer" <chris@tufware.com.au> wrote in message
>> > news:G3pwocSKFHA.7472@dacmail.dataaccess.com...
>> >
>> >>I agree. Get rid of underscores, but for backwards sake (if an issues)
>> >>have the old methods call the newer ones
>> >>
>> >>
>> >>
>> >>Chris Spencer
>> >>TUFware Systems
>> >>
>> >>"Garret Mott" <garret@automatesoftware.com> wrote in message
>> >>news:imghcgJKFHA.5816@dacmail.dataaccess.com...
>> >>
>> >>>And one more thing: underscores:
>> >>>
>> >>>CurrentRowTextColor
>> >>>Column_Shadow_State
>> >>>
>> >>>I'd love to see them consistent as well. OK - I'd really like all the
>> >>>underscores to go away, since my feeling is that this is a holdover
> from
>> >>>"all caps" programming days. Others may (probably do?) disagree.
>> >>>
>> >>>Garret
>> >>>
>> >>>"Garret Mott" <garret@automatesoftware.com> wrote in message
>> >>>news:RQQMfFDKFHA.7024@dacmail.dataaccess.com...
>> >>>
>> >>>>Hi All -
>> >>>>
>> >>>>I started this topic in the Ver. 11 Alpha NG kind of by accident. I
>> >>>>said I would post it here, so here it is.
>> >>>>
>> >>>>DF & VDF have been around a long time. The language has matured
> greatly
>> >>>>over this time, but not without growing pains. To me, one of the
>> >>>>biggest issues is lack of consistency in naming of properties, events
> &
>> >>>>methods.
>> >>>>
>> >>>>Various posts in various places have talked about this, but I thought
> it
>> >>>>might be good to get some discussion under a new thread.
>> >>>>
>> >>>>One of the things that prompts me to do so is a reply I received from
>> >>>>John Tuohy (in the Ver. 11 Alpha NG):
>> >>>><JT>
>> >>>>This is a big topic and this is probably not the best place to dig
> into
>> >>>>it but here is the short answer. We have a lot of history in our
> naming
>> >>>>conventions. They've been around for a lot of years and they've
> changed
>> >>>>a lot over the years (and not always in the most consistent fashion).
> We
>> >>>>can't change old names and there is never a single rule we can apply
> to
>> >>>>creating new names. Sometimes we use older style names to create
>> >>>>consistency with existing messages, sometimes we use whatever we
> happens
>> >>>>to be our current naming convention and sometimes we use some kind of
>> >>>>mix.
>> >>>></JT>
>> >>>>
>> >>>>While this all makes sense, I'm thinking that at some point it needs
> to
>> >>>>change. (DAW- don't you just love your customers telling you what to
>> >>>>do?;-) Many of us have "grown up" with DF, so we've seen the changes
>> >>>>occur gradually. Now picture coming into the language cold. Wow!
> What
>> >>>>a learning curve.
>> >>>>
>> >>>>Think of this when looking through help in a new language:
>> >>>>
>> >>>>Properties: TypeFace & psTypeFace, FontSize & piFontSize for
>> >>>>example.
>> >>>>In general, why do some have the "p*" prefix & some not? Why Font &
>> >>>>TypeFace?
>> >>>>
>> >>>>Methods: Confirm, Message_Box, Stop_Box, YesNo_Box, YesNoCancel_Box
>> >>>>Shouldn't there be one function that has properties to set it to what
>> >>>>you want? Message_Box comes closest, but why all the others? How
> about
>> >>>>InputBox, while we're at it? OK, now - which are procedures & which
> are
>> >>>>functions? Do I "Get" this one or "Send" it? Then names: I think
>> >>>>it
>> >>>>was Wil van Antwerpen who brought up the "Do" prefix for methods
>> >>>>concept. Whatever the convention, consistency would be best
>> >>>>
>> >>>>Events: In dbGrid you have Column_Combo_Fill_List &
> Combo_Edit_Changed.
>> >>>>Why is one preceded by "Column_" & the other not? Why does
>> >>>>Column_Shadow_State work differently than Item_Shadow_State?
>> >>>>
>> >>>>These are just a few examples, and probably not the least consistent.
> I
>> >>>>don't know what can be done for properties (except maybe a bunch of
>> >>>>"#Replace"s - oops - "Define"s?), but it seems to me that Events &
>> >>>>Methods could be cleaned up with wrappers:
>> >>>>
>> >>>>Procedure Column_Combo_Edit_Changed integer iItem
>> >>>> Send Combo_Edit_Changed iItem
>> >>>>End_Procedure
>> >>>>
>> >>>>Yes, there's some overhead, but would it make that big a difference?
>> >>>>Maybe I'm nuts, and probably many folks have better
> solutions/thoughts,
>> >>>>but I wanted to get this out here.
>> >>>>
>> >>>>Thanks for listening,
>> >>>>
>> >>>>Garret
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>> >
>
>