POV-Ray : Newsgroups : povray.general : macro naming convention Server Time
31 Oct 2024 06:14:58 EDT (-0400)
  macro naming convention (Message 1 to 10 of 10)  
From: And
Subject: macro naming convention
Date: 12 Jul 2023 04:20:00
Message: <web.64ae610aa242ba4bee1d8e88aa81652d@news.povray.org>
Is there some suggestion about naming macro / naming function?

should macro name start with uppercase?


Post a reply to this message

From: jr
Subject: Re: macro naming convention
Date: 12 Jul 2023 05:55:00
Message: <web.64ae775dc7533f87b49d80446cde94f1@news.povray.org>
hi,

"And" <49341109@ntnu.edu.tw> wrote:
> Is there some suggestion about naming macro / naming function?
>
> should macro name start with uppercase?

I'd better not get into the upper vs lowercase debate :-).  but if you think the
code may be published in future, I'd recommend sticking with the conventions
enumerated in the Object Collection (which still is offline, for the time being)
documentation.  Cousin Ricky posted a v good summary of "the rules", see section
'namespace compliance'; <http://news.povray.org/64014f55%40news.povray.org>.


regards, jr.


Post a reply to this message

From: ingo
Subject: Re: macro naming convention
Date: 12 Jul 2023 06:10:00
Message: <web.64ae7b15c7533f8717bac71e8ffb8ce3@news.povray.org>
"And" <49341109@ntnu.edu.tw> wrote:
> should macro name start with uppercase?

Yes, I think so, to avoid collisions with the SDL

For macro's inside an include file I tend to prepend the name with a few
'meaningfull' capitals.

Macro's inside a Singly Linked List include look like
SLLInit()
SLLPush()
SLLAdd()
SLLPop()
SLLPeek()
....

For macro's and variables that are private to an include file I tend to prepend
them with an underscore.

ingo


Post a reply to this message

From: Alain Martel
Subject: Re: macro naming convention
Date: 12 Jul 2023 15:38:25
Message: <64af0131$1@news.povray.org>
Le 2023-07-12 à 04:15, And a écrit :
> Is there some suggestion about naming macro / naming function?
> 
> should macro name start with uppercase?
> 

The name of macros and functions should contain an upper case character 
to avoid any name collision with SDL's key words that are always all 
lowercase.
The convention is to start with an uppercase character, but, it's up to you.
The suggestion from Ingo is a good one.


Post a reply to this message

From: And
Subject: Re: macro naming convention
Date: 12 Jul 2023 23:50:00
Message: <web.64af738ec7533f87ee1d8e88aa81652d@news.povray.org>
Alain Martel <kua### [at] videotronca> wrote:

> > Is there some suggestion about naming macro / naming function?
> >
> > should macro name start with uppercase?
> >
>
> The name of macros and functions should contain an upper case character
> to avoid any name collision with SDL's key words that are always all
> lowercase.
> The convention is to start with an uppercase character, but, it's up to you.
> The suggestion from Ingo is a good one.

Thank you.


Post a reply to this message

From: And
Subject: Re: macro naming convention
Date: 13 Jul 2023 00:05:00
Message: <web.64af777ac7533f87ee1d8e88aa81652d@news.povray.org>
"ingo" <nomail@nomail> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > should macro name start with uppercase?
>
> Yes, I think so, to avoid collisions with the SDL
>
> For macro's inside an include file I tend to prepend the name with a few
> 'meaningfull' capitals.
>
> Macro's inside a Singly Linked List include look like
> SLLInit()
> SLLPush()
> SLLAdd()
> SLLPop()
> SLLPeek()
> ....
>
> For macro's and variables that are private to an include file I tend to prepend
> them with an underscore.
>
> ingo


Is it a good idea offer only one (public using) macro in an include file?

I just see someone use two underscore __ to connect words, then use another one
underscore _ , I would like to know the occasion.


Post a reply to this message

From: And
Subject: Re: macro naming convention
Date: 13 Jul 2023 00:10:00
Message: <web.64af7856c7533f87ee1d8e88aa81652d@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "And" <49341109@ntnu.edu.tw> wrote:
> > Is there some suggestion about naming macro / naming function?
> >
> > should macro name start with uppercase?
>
> I'd better not get into the upper vs lowercase debate :-).  but if you think the
> code may be published in future, I'd recommend sticking with the conventions
> enumerated in the Object Collection (which still is offline, for the time being)
> documentation.  Cousin Ricky posted a v good summary of "the rules", see section
> 'namespace compliance'; <http://news.povray.org/64014f55%40news.povray.org>.
>
>
> regards, jr.

Thank you. I happen to download some POV-Object-Collection written by Cousin
Ricky from Github yesterday.


Post a reply to this message

From: jr
Subject: Re: macro naming convention
Date: 13 Jul 2023 04:25:00
Message: <web.64afb41bc7533f87b49d80446cde94f1@news.povray.org>
hi,

"And" <49341109@ntnu.edu.tw> wrote:
> ...
> Thank you. I happen to download some POV-Object-Collection written by Cousin
> Ricky from Github yesterday.

I think his sum-up is pretty comprehensive.


> I just see someone use two underscore __ to connect words ...

I have started doing this (too), used for internal-to-inc-file macros / names.


regards, jr.


Post a reply to this message

From: Alain Martel
Subject: Re: macro naming convention
Date: 13 Jul 2023 08:10:20
Message: <64afe9ac$1@news.povray.org>
Le 2023-07-13 à 00:03, And a écrit :

> 
> Is it a good idea offer only one (public using) macro in an include file?
> 
> I just see someone use two underscore __ to connect words, then use another one
> underscore _ , I would like to know the occasion.
> 
There is no real reason to have only one macro per include. In fact, is 
you look at the distribution, you'll find several includes that provide 
several macros.

The good practice would be to bundle macros that are somewhat related.


Post a reply to this message

From: And
Subject: Re: macro naming convention
Date: 13 Jul 2023 11:20:00
Message: <web.64b01533c7533f87ee1d8e88aa81652d@news.povray.org>
Thanks.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.