On Friday, 18 January 2013 at 10:40:50 UTC, Mehrdad wrote:
> On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:
>> If you believe you know operator precedence, you are probably wrong. And even if you are right, most other programmer don't.
>
>
> They're not /that/ bad...
>
> + - * / %  are like in math
> << >>      are harder, but all you need is to recall that cout << x + 2;
>            works as written
> |  &       are just like in math (or is addition, and is multiplication)
> ^          is in between | and &
> || &&      are just like in math (or is addition, and is multiplication)


that takes care of helping you remember all the 'sane' cases so you don't need parentheses.

If you're doing something obscure like    x = x | y || w & z && 5 | 6 || 7;
then yeah, you should seriously put parentheses.

On Friday, January 18, 2013 11:30:32 deadalnix wrote:
> If you believe you know operator precedence, you are probably wrong. And even if you are right, most other programmer don't.

You really should know the precedence of at least the common operators. For instance, I don't think that there's much excuse for code like

if((a == b) && (c != d))

The parens just clutter the code, and any programmer worth their salt should know that the comparison operators has higher precedence than the logical operators. And programmers should definitley know the precedence of the arithmetic operators, such that if they're putting parens around ever expression using + or *, then there's a problem.

On the other hand, I can totally understand if someone is nervous about doing stuff like

if(++*var == a)

I fully expect that your average programmer won't fully know the operator precedence table. _I_ don't know it perfectly. But for the more common operators, you should know it, and using extra parens in those cases just makes the code harder to read.

- Jonathan M Davis

On 1/18/2013 12:58 AM, Timon Gehr wrote:
> On 01/18/2013 09:48 AM, Walter Bright wrote:
>> On 1/17/2013 11:58 PM, Artur Skawina wrote:
>>> Sane, but badly formatted code is much preferable to bad, but pretty
>>> code.
>>
>> Offhand, I can't remember ever running across bad but pretty code.
>
> Some of the worst code I have seen has been consistently formatted.

pretty is not iff consistently formatted

On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote: […]
> But in practice, I find over and over again that carefully formatted code tends to go hand in hand with well designed code.

Having an obsessive–compulsive side to your nature is good in these case.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis wrote:
> On Friday, January 18, 2013 11:30:32 deadalnix wrote:
>> If you believe you know operator precedence, you are probably
>> wrong. And even if you are right, most other programmer don't.
>
> You really should know the precedence of at least the common operators. For
> instance, I don't think that there's much excuse for code like
>
> if((a == b) && (c != d))
>
> The parens just clutter the code, and any programmer worth their salt should
> know that the comparison operators has higher precedence than the logical
> operators. And programmers should definitley know the precedence of the
> arithmetic operators, such that if they're putting parens around ever
> expression using + or *, then there's a problem.
>
> On the other hand, I can totally understand if someone is nervous about doing
> stuff like
>
> if(++*var == a)
>
> I fully expect that your average programmer won't fully know the operator
> precedence table. _I_ don't know it perfectly. But for the more common
> operators, you should know it, and using extra parens in those cases just
> makes the code harder to read.
>
> - Jonathan M Davis

Keep in mind that us, as enthusiasts, have a warped view on the matter.

A lot of my "programmer" colleagues don't really give a damn, and, for them, precedence stops at arithmetic operators. I'm not saying they are bad programmers, but they just can't be arsed with that kind of stuff: They just don't care.

*Personally*, I prefer
    if ((a == b) && (c != d))
over
    if (a == b && c != d)

I *know* the precedence here, but I still find it clearer with grouping.

HOWEVER, I 100% agree that in such code, the format chosen is very very important. Place spaces in the wrong spots:
    if ( ( a == b ) && ( c != d ) )
And the eyes begin to bleed...

As a side note, I've taken to ALWAYS placing parenthesis with ternary operators. That thing has some nasty precedence rules...

On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis wrote:
> You really should know the precedence of at least the common operators. For instance, I don't think that there's much excuse for code like
>
> if((a == b) && (c != d))

 Unfortunately I've come across a few cases (and in dmd too) where compiles it wrong if you don't and get unwanted/unexpected/buggy behavior; So the code looks similar to that (but not by choice).

 I 'think' it was something like 'if(a + 2 > b)', but I'd have to dig them out to know for among hundreds of lines of code.

 The exact order of precedence has always eluded me and are a set of rules I'll never completely remember. However I do know that multiplication and division are above addition and subtraction, which is the only real place I've come to rely on it a few times to remove excess parentheses.

On 01/18/2013 01:13 PM, monarch_dodra wrote:
> ...
>
> *Personally*, I prefer
>      if ((a == b) && (c != d))
> over
>      if (a == b && c != d)
>
> I *know* the precedence here, but I still find it clearer with grouping.
>
> HOWEVER, I 100% agree that in such code, the format chosen is very very
> important. Place spaces in the wrong spots:
>      if ( ( a == b ) && ( c != d ) )
> And the eyes begin to bleed...
>

if(a==b && c!=d)

> As a side note, I've taken to ALWAYS placing parenthesis with ternary
> operators. That thing has some nasty precedence rules...

auto a = b && x ? c :
         d || y ? e :
         f ^ z  ? g :
                  h ;

monarch_dodra:

> As a side note, I've taken to ALWAYS placing parenthesis with ternary operators. That thing has some nasty precedence rules...

Then please vote :-)

http://d.puremagic.com/issues/show_bug.cgi?id=8757

Bye,
bearophile

On Tuesday, 15 January 2013 at 14:07:11 UTC, monarch_dodra wrote:
> On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:
>> On 01/15/2013 11:57 AM, mist wrote:
>>> Well, probably I am playing "good vision nazi" here, as 12 font size
>>> seems HUGE to me, far beyond the comfort zone.
>>
>> It's just preference. I do not have any problems with font size 9.
>
> I do not know of any editor that does not support "ctrl + scroll" to change the font sizes on the fly.

FWIW, Emacs doesn't out of the box. But this makes it work:

(global-set-key [M-mouse-4] 'text-scale-increase)
(global-set-key [M-mouse-5] 'text-scale-decrease)

(M- for Alt, or C- for Control.)

Graham

On Fri, 2013-01-18 at 17:52 +0100, Graham Fawcett wrote: […]
> FWIW, Emacs doesn't out of the box. But this makes it work:
> 
> (global-set-key [M-mouse-4] 'text-scale-increase)
> (global-set-key [M-mouse-5] 'text-scale-decrease)
> 
> (M- for Alt, or C- for Control.)

Graham,

I am going to count the above as four things I learnt today. Splendid, no more need to use GEdit. Excellent.

Thanks.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder