You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Malcolm J Harwood <mj...@liminalflux.net> on 2006/01/26 02:59:14 UTC
Re: svn commit: r372010 - /perl/modperl/trunk/src/modules/perl/modperl_cmd.c
On Wednesday 25 January 2006 11:29 pm, Philip M. Gollucci wrote:
> >- if(0 == strncasecmp(arg, "+inherit", 8)) {
> >+ if (0 == strncasecmp(arg, "+inherit", 8)) {
> > modperl_cmd_options(parms, mconfig, "+InheritSwitches");
> > }
> > else {
>
> Isn't the normal c idiom
> if (!strncasecmp(....) ?
> I don't think I've ever seen that form.... (though correct)
It's somewhat more common with C++. The logic is this:
if you typo:
if (var == 0) ...
as
if (var = 0) ...
it will compile, often without even a warning (though more recent versions of
gcc do complain), but not do what you expect and the bug can be very hard to
spot. However if you typo:
if (0 == var) ...
as
if (0 = var) ...
you'll get a compile time error, as you can't assign to a constant. So whilst
it reads strangely to most people, some get in the habit of using that form.
It wouldn't make a difference in this case, as far as I can tell though.
--
"I just think it's rather odd that a nation that prides itself on its virility
should feel compelled to strap on forty pounds of protective gear just in
order to play rugby."
- Giles, Buffy the Vampires Slayer: Some Assembly Required
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: svn commit: r372010 - /perl/modperl/trunk/src/modules/perl/modperl_cmd.c
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> [...]
>
>>Yes! That's also another _very_ good reason to type comparaisons with the constant
>>on the left side. I always try to write it in that order, and by now, my brain
>>is fully adjusted to it.
>>
>>if ("Inherit" eq $var) {
>>elsif ("Enable" eq $var) {
>>elsif ("Disable" eq $var) {
>>
>>Also puts the things being looked for first, making the statement somewhat clearer
>>to me.
>
> I suppose when all you use is a hammer, everything looks like a nail :)
>
> What if sometimes it's $var and at other times $bar? e.g. what reads better:
>
> if ("FooBar" eq $var) {
> elsif ("444" eq $bar) {
> elsif ("foobartar" eq $bar) {
>
> or:
>
> if ($var eq "FooBar") {
> elsif ($bar eq "444") {
> elsif ($bar eq "foobartar") {
>
> the second version is much more parsable if you ask me.
Yup, I agree with you in that example. In cascasing if/elsif/elsif,
I guess the trick is to try and keep the most significant element of
the comparaison to the left.
> I admit my variables nicely align, which makes it easier to read :)
if ("FooBar" eq $var) {
elsif ("444" eq $bar) {
elsif ("foobartar" eq $bar) {
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: svn commit: r372010 - /perl/modperl/trunk/src/modules/perl/modperl_cmd.c
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
[...]
> Yes! That's also another _very_ good reason to type comparaisons with the constant
> on the left side. I always try to write it in that order, and by now, my brain
> is fully adjusted to it.
>
> if ("Inherit" eq $var) {
> elsif ("Enable" eq $var) {
> elsif ("Disable" eq $var) {
>
> Also puts the things being looked for first, making the statement somewhat clearer
> to me.
I suppose when all you use is a hammer, everything looks like a nail :)
What if sometimes it's $var and at other times $bar? e.g. what reads better:
if ("FooBar" eq $var) {
elsif ("444" eq $bar) {
elsif ("foobartar" eq $bar) {
or:
if ($var eq "FooBar") {
elsif ($bar eq "444") {
elsif ($bar eq "foobartar") {
the second version is much more parsable if you ask me.
I admit my variables nicely align, which makes it easier to read :)
--
_____________________________________________________________
Stas Bekman mailto:stas@stason.org http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: svn commit: r372010 - /perl/modperl/trunk/src/modules/perl/modperl_cmd.c
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Malcolm J Harwood wrote:
> On Wednesday 25 January 2006 11:29 pm, Philip M. Gollucci wrote:
>
>
>>>- if(0 == strncasecmp(arg, "+inherit", 8)) {
>>>+ if (0 == strncasecmp(arg, "+inherit", 8)) {
>>> modperl_cmd_options(parms, mconfig, "+InheritSwitches");
>>> }
>>> else {
>>
>>Isn't the normal c idiom
>>if (!strncasecmp(....) ?
>
>>I don't think I've ever seen that form.... (though correct)
>
> It's somewhat more common with C++. The logic is this:
> if you typo:
> if (var == 0) ...
> as
> if (var = 0) ...
> it will compile, often without even a warning (though more recent versions of
> gcc do complain), but not do what you expect and the bug can be very hard to
> spot. However if you typo:
> if (0 == var) ...
> as
> if (0 = var) ...
> you'll get a compile time error, as you can't assign to a constant. So whilst
> it reads strangely to most people, some get in the habit of using that form.
> It wouldn't make a difference in this case, as far as I can tell though.
Yes! That's also another _very_ good reason to type comparaisons with the constant
on the left side. I always try to write it in that order, and by now, my brain
is fully adjusted to it.
if ("Inherit" eq $var) {
elsif ("Enable" eq $var) {
elsif ("Disable" eq $var) {
Also puts the things being looked for first, making the statement somewhat clearer
to me.
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5