You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Doug MacEachern <do...@covalent.net> on 2001/10/18 21:50:11 UTC
Re: #define style + functions layout
On Mon, 24 Sep 2001, Stas Bekman wrote:
> #define merge_item(item) \
> mrg->item = add->item ? add->item : base->item
>
> #define merge_handlers(merge_flag, array) \
> if (merge_flag(mrg)) { \
> ...
>
> Personally I like (b) better (4 indent), as it's easier to tell the
> numerous defines from their bodies :)
i guess my habit is just not indenting 1 liner defines. indenting those
is fine though.
> Another question is placement of functions in Perl and C code. As the
> code gets developed new functions are many times added in the ad-hoc
> placement -- i.e. some functions spring next to the place they are
> needed, some function are prepended to the top, some go to the bottom.
> It's much easier to understand unfamiliar code if the functions are
> defined in some logical order.
i have tried to keep a logical order.
> Is it ok to reshuffle some of the functions and commit as I read the
> code? e.g. in modperl_config.c currently we have:
no, i don't want any functions shuffled around at this point.
if you want to add todos be thought about later that's fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: #define style + functions layout
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Mon, 24 Sep 2001, Stas Bekman wrote:
>
>
>>#define merge_item(item) \
>>mrg->item = add->item ? add->item : base->item
>>
>>#define merge_handlers(merge_flag, array) \
>> if (merge_flag(mrg)) { \
>> ...
>>
>>Personally I like (b) better (4 indent), as it's easier to tell the
>>numerous defines from their bodies :)
>>
>
> i guess my habit is just not indenting 1 liner defines. indenting those
> is fine though.
ok
>>Another question is placement of functions in Perl and C code. As the
>>code gets developed new functions are many times added in the ad-hoc
>>placement -- i.e. some functions spring next to the place they are
>>needed, some function are prepended to the top, some go to the bottom.
>>It's much easier to understand unfamiliar code if the functions are
>>defined in some logical order.
>>
>
> i have tried to keep a logical order.
i know you are, but there are a few places where with a time the
functions aren't in very logical order, I guess it depends on the
personal definitions of logical order :)
>>Is it ok to reshuffle some of the functions and commit as I read the
>>code? e.g. in modperl_config.c currently we have:
>>
>
> no, i don't want any functions shuffled around at this point.
> if you want to add todos be thought about later that's fine.
no prob,
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org