Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > mnemonic

Reply
Thread Tools

mnemonic

 
 
Ben Pfaff
Guest
Posts: n/a
 
      11-01-2007
Eric Sosman <(E-Mail Removed)> writes:

> Even if Joe Coder knows the precedence rules perfectly
> and can parse
>
> if ( a && b | c && d )
>
> without blinking, he may still wonder whether *you* were
> entirely familiar with the rules:


With or without additional parentheses, I'd be inclined to think
that | should be || in the above. (In context, it would probably
be obvious whether | was correct.)
--
"Am I missing something?"
--Dan Pop
 
Reply With Quote
 
 
 
 
Al Balmer
Guest
Posts: n/a
 
      11-01-2007
On Thu, 1 Nov 2007 22:28:13 +0100, "Serve Lau" <(E-Mail Removed)> wrote:

>
><(E-Mail Removed)> wrote in message
>news:(E-Mail Removed) roups.com...
>> Parentheses can be annoying and useless in code.
>> The solution is to learn operator precedence.

>
>I use the parentheses rule too when in doubt, but when they become too
>"annoying" in certain expression, only then I look up the rules in a book or
>something to make that expression clearer. No need remembering the
>precedence rules by heart
>

In such cases, you'd probably be better off studying your code to see
why it appears so complex.

“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” – Brian W. Kernighan

--
Al Balmer
Sun City, AZ
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      11-01-2007
Ben Pfaff wrote On 11/01/07 17:48,:
> Eric Sosman <(E-Mail Removed)> writes:
>
>
>> Even if Joe Coder knows the precedence rules perfectly
>>and can parse
>>
>> if ( a && b | c && d )
>>
>>without blinking, he may still wonder whether *you* were
>>entirely familiar with the rules:

>
>
> With or without additional parentheses, I'd be inclined to think
> that | should be || in the above. (In context, it would probably
> be obvious whether | was correct.)


My point is that one would not need to rely on one's
inclinations or suppositions if the author had written

if ( a && (b | c) && d )
or even
if ( a && (b | c) != 0 && d )

As for obviousness: Yes, you can usually figure out
what the code *should* mean, but sometimes the project
becomes as intricate as a CSI episode (and less exciting).
Whenever I've had to spend time deciding that something
was really intended and not a typo, I've added parentheses
or a zero comparison or something of the kind so that the
next person won't have to sleuth it out all over again (and
maybe get it wrong).

Two kinds of readers peruse source code: computers and
people, and the latter are the more important readership.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      11-01-2007
Al Balmer <(E-Mail Removed)> writes:

> On Thu, 1 Nov 2007 22:28:13 +0100, "Serve Lau" <(E-Mail Removed)> wrote:
>
>>
>><(E-Mail Removed)> wrote in message
>>news:(E-Mail Removed) groups.com...
>>> Parentheses can be annoying and useless in code.
>>> The solution is to learn operator precedence.

>>
>>I use the parentheses rule too when in doubt, but when they become too
>>"annoying" in certain expression, only then I look up the rules in a book or
>>something to make that expression clearer. No need remembering the
>>precedence rules by heart
>>

> In such cases, you'd probably be better off studying your code to see
> why it appears so complex.
>
> “Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are, by
> definition, not smart enough to debug it.” – Brian W. Kernighan


This quote is maybe sometimes applicable. But not always.

Debugging well structured and documented code is generally quite
easy. Especially when combined with HW break points and expression
watches.

I have debugged a LOT of large systems and fixed them without having the
need to understand the entire system.


 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      11-01-2007
In article <(E-Mail Removed) om>,
<(E-Mail Removed)> wrote:

>Is there any mnemonic for remembering C precedence rules????


If you need a mnemonic, you shouldn't be trying to do it.

If you have trouble remembering the order, use parentheses.

Some rules are obvious: && and || bind less strongly than comparison
operators, which in turn bind less strongly than arithmetic operators,
because otherwise the 90% case of conditions like if(a == b+c) would
need extra parentheses. Assignment binds weakly for the same reason.
You may be able to find convincing explanations for some of the others,
but if you can't see why addition binds more strongly than shift why
bother? Quite likely your readers can't either.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      11-01-2007
Eric Sosman <(E-Mail Removed)> writes:

> Ben Pfaff wrote On 11/01/07 17:48,:
>> Eric Sosman <(E-Mail Removed)> writes:
>>
>>
>>> Even if Joe Coder knows the precedence rules perfectly
>>>and can parse
>>>
>>> if ( a && b | c && d )
>>>
>>>without blinking, he may still wonder whether *you* were
>>>entirely familiar with the rules:

>>
>>
>> With or without additional parentheses, I'd be inclined to think
>> that | should be || in the above. (In context, it would probably
>> be obvious whether | was correct.)

>
> My point is that one would not need to rely on one's
> inclinations or suppositions if the author had written
>
> if ( a && (b | c) && d )
> or even
> if ( a && (b | c) != 0 && d )


To me, your article quoted above raises two points: precedence
and correct choice of operators. I chose to comment on the
latter. In my opinion, the point about precedence could have
been made just as effectively using || instead of |.

> As for obviousness: Yes, you can usually figure out
> what the code *should* mean, but sometimes the project
> becomes as intricate as a CSI episode (and less exciting).
> Whenever I've had to spend time deciding that something
> was really intended and not a typo, I've added parentheses
> or a zero comparison or something of the kind so that the
> next person won't have to sleuth it out all over again (and
> maybe get it wrong).
>
> Two kinds of readers peruse source code: computers and
> people, and the latter are the more important readership.


I heartily agree.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-02-2007
Julienne Walker wrote:
> (E-Mail Removed) wrote:
>
>> Parentheses can be annoying and useless in code.

>
> They can be, if you use them abusively. On the other hand, *lack*
> of parentheses can be annoying and useless in code for the same
> reason.
>
>> The solution is to learn operator precedence.

>
> Perhaps *you* have perfect memory, but *I* don't. I'd rather
> remember a simple guideline than a slew of rules, because to be
> perfectly frank, I have better things to spend my few remaining
> brain cells on.


I limit my precedence memory to: Multiplicative ops, additive ops,
relational ops. If anything further is needed, make it clear (and
sure) with the appropriate parentheses.

You'ld be surprised how many languages this serves!

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-02-2007
Richard wrote:
> Al Balmer <(E-Mail Removed)> writes:
> [...]
>> “Debugging is twice as hard as writing the code in the first place.
>> Therefore, if you write the code as cleverly as possible, you are, by
>> definition, not smart enough to debug it.” – Brian W. Kernighan

>
> This quote is maybe sometimes applicable. But not always.
>
> Debugging well structured and documented code is generally quite
> easy. [...]


The only empirical study I'm aware of came to the opposite
conclusion. A bunch of computer science students were handed
an existing program and told to debug it. Half received the
program as originally written, half received the same program
minus all its comments. The comment-less group found more of
the bugs and found them faster. So much for documentation.

I think the experiment was described in "The Psychology of
Computer Programming," but I can't remember for sure. The authors
speculated that the comments led the readers down the same paths
of fallacious reasoning that the original code writers followed
when they wrote the bugs in the first place.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      11-02-2007
Eric Sosman <(E-Mail Removed)> writes:

> Richard wrote:
>> Al Balmer <(E-Mail Removed)> writes:
>> [...]
>>> “Debugging is twice as hard as writing the code in the first place.
>>> Therefore, if you write the code as cleverly as possible, you are, by
>>> definition, not smart enough to debug it.” – Brian W. Kernighan

>>
>> This quote is maybe sometimes applicable. But not always.
>>
>> Debugging well structured and documented code is generally quite
>> easy. [...]

>
> The only empirical study I'm aware of came to the opposite
> conclusion. A bunch of computer science students were handed
> an existing program and told to debug it. Half received the
> program as originally written, half received the same program
> minus all its comments. The comment-less group found more of
> the bugs and found them faster. So much for documentation.
>
> I think the experiment was described in "The Psychology of
> Computer Programming," but I can't remember for sure. The authors
> speculated that the comments led the readers down the same paths
> of fallacious reasoning that the original code writers followed
> when they wrote the bugs in the first place.


Depends on your familiarity with the code and how well you know how to use
a debugger. Some people are just good at it - binary chop and gut
instinct.

 
Reply With Quote
 
Tim Brown
Guest
Posts: n/a
 
      11-02-2007
(E-Mail Removed) wrote:
>
> or is there any simple mnemonic such as
>
> "How I want a sweetened drink of course after the heavy lectures
> involving quantum mechanics" which is mainly used by math pros for
> remembering Pi value(3.14195265358979)
>


woopsie!

your "sweetened drink" should be "drink sweetened" to make the pi value
come out correctly


Tim
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Swing, customize the behavior of mnemonic access subwiz Java 1 09-19-2008 01:33 AM
Mnemonic jacob navia C Programming 40 11-10-2007 12:56 AM
/m, /s: better mnemonic than "multiple", "single"? J Krugman Perl Misc 2 05-19-2004 07:44 PM
Johnny Mnemonic Kenneth Ulicni DVD Video 4 10-29-2003 03:34 AM



Advertisments