Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Jolly Roger <jollyroger@pobox.com>
Newsgroups: comp.sys.mac.system
Subject: Re: Latest IOS/OS X SSL security flaw
Date: 25 Feb 2014 17:00:12 GMT
Organization: People for the Ethical Treatment of Pirates
Lines: 70
Message-ID: <bn40grF96u7U3@mid.individual.net>
References: <lears8$l8d$1@dont-email.me> <220220141415089899%nospam@nospam.invalid> <2NWdnQXy6oxRY5XOnZ2dnUVZ_qSdnZ2d@giganews.com> <bmsj7oFmdpqU4@mid.individual.net> <L-SdnavB-Z27ppTOnZ2dnUVZ_uKdnZ2d@giganews.com> <bmsu50Fnr6sU2@mid.individual.net> <led5e1$4q9$1@dont-email.me> <slrnlglhj1.fcb.g.kreme@amelia.local> <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com> <slrnlgoki2.1jei.g.kreme@oswin.local>
X-Trace: individual.net QyipMP4a1+DAicXR+OhHdgFfp5EzrRuRr3EYXgw5e0Js2SKHRW
Cancel-Lock: sha1:QX/08vFnBJMCq3ebAlTQjJ936tM=
X-Face: _.g>n!a$f3/H3jA]>9pN55*5<`}Tud57>1<n@LQ!aZ7vLO_nWbK~@T'XIS0,oAJcU.qLM dk/j8Udo?O"o9B9Jyx+ez2:B<nx(k3EdHnTvB]'eoVaR495,Rv~/vPa[e^JI+^h5Zk*i`Q;ezqDW< ZFs6kmAJWZjOH\8[$$7jm,Ogw3C_%QM'|H6nygNGhhl+@}n30Nz(^vWo@h>Y%b|b-Y~()~\t,LZ3e up1/bO{=-)
User-Agent: slrn/1.0.1 (Darwin)
Xref: csiph.com comp.sys.mac.system:57071

On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com> 
>   Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.23, 23:11 , Lewis wrote:
>>> In message <led5e1$4q9$1@dont-email.me>
>>>    Don Bruder <dakidd@sonic.net> wrote:
>>>> I tend toward "overkill unto the verge of paranoia" when bracing
>>>> conditionals, for exactly that reason. Even though I'm quite aware that
>>>> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
>>>> much as a hiccup, if I'm coding something that needs that sort of
>>>> construct, I'm most likely going to write it as
>>>> if (foo)
>>>>    {
>>>>      bar(foo);
>>>>   }
>>>> else
>>>>    {
>>>>      // It's a bad idea to bar() a nil foo
>>>>   }
>>>
>>> I like more compact code:
>>>
>>> if (foo) { bar(foo); }
>
>> Pascal:
>
>>    if foo then bar(foo);
>
>> Much more readable.
>
> Not really.
>
>
>  if (foo) { bar(foo); }
>     a = a + 1;
>
>  if foo then bar(foo);
>     a = a + 1;
>
> The first (C) example is much clearer to me that the assignment line is
> *not* part of the if block.

Agreed.

That said, I dislike your approach of placing as much as possible on a
single line. It's not as easy to scan through many lines of such code as
it would be if things weren't stacked up like that, and it doesn't make
things easy for the developer later on when you need to add additional
comments and statements inside of the if clause. So I tend to adhere to
this expanded format instead, so that modification down the line is as
easy as possible:

if (foo)
{
	// blah blah blah
	bar(foo);
	b = a * c;
}
a = a + 1;

To each, their own, of course; but I'm always doing my best to think
ahead and consider that the code I write will probably need to be
modified by someone else at some point in the future. One of my goals
is to make that job as easy as I can for them.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR