View mode: basic / threaded / horizontal-split · Log in · Help
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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...
January 18, 2013
Re: Exceptional coding style
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.
January 18, 2013
Re: Exceptional coding style
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 ;
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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
January 18, 2013
Re: Exceptional coding style
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
14 15 16 17 18 19 20
Top | Discussion index | About this forum | D home