C - <= and >= Problems

[GCDEF]

A simple example

A && B || C

You could assume that the coder knows the operator precedence and it does what he intended.

If he were to type A && (B || C) then it doesn't matter whether the coder remembers && or || has the higher precedence, it will work as intended.
Now imagine a much longer and more complicated logic test.
I stick to this principle because it alleviates having to debug silly mistakes and lets me concentrate on the bigger issues.

If parenthesis are superfluous, then what about spaces and carriage returns?

#include<iostream>
#include<string>
int main(){std::string name;std::cout<<"Name?";std::cin>>name;std::cout<<"Hello "<<name;}

It's not about whether things are superfluous or not, it's about readability and conciseness of meaning;

Spaces and carriage returns are for readability. Parenthesis are there for grouping to change the natural order of evaluation. Spaces don't change logic. Parenthesis do, so when they're there, it's assumed that they're there to affect logic, at least by me. Maybe they make it more readable to you but to me they're there to change the normal order of evaluation and it seems strange to add them when they do nothing.

In the code in this case it's a simple logical and. There's nothing confusing or ambiguous about it.

[treuss]

A simple example

A && B || C

That's a total different kind of beef than a < b && b < c.

&& and || are from a logical point of view equal types of operators, so the preference ordering in C is purely autocratic.

< and && are different types of operators and the C language luckily follows common sense here and defines the preference ordering as one would expect.a < b && b < c should make sense to anyone without knowing the preference order by heart.

[JohnW@Wessex]

Maybe they make it more readable to you but to me they're there to change the normal order of evaluation and it seems strange to add them when they do nothing.

My coding style preferences come after many, many years of coding and debugging (often other people's code). Over the years I have moved to a principle of coding in a style that is much more verbose. I add in 'superfluous' parentheses; I test explicitly for zero/non-zero rather that using the implicit conversion to bool + many other 'useless' things. I do all this (and wrote it into the coding style) because it all but eliminates most of the dumb mistakes people make. I've found that it's not a good idea to assume that has the same interpretation of 'obvious'.

[potatoCode]

================================================================================
BBCode Version 0.10 (freeware)
Author: potatoCode on forum www.codeguru.com
================================================================================

int convert( const char Val[], int Base , int * InValue ) 
{ 
int i; 
int count = 0; 
bool negFlag = 0; 
for( i = 0 ;; i++ ) 
{ 
if ( Val[i] == '\0' ) 
{ 
break; 
} 
printf ( "%i\n" , Val[i] ); 
if (Val[i]<=90 || Val[i]>=65); 
{ 
printf ( "%i\n" , count ); 
count++; 
} 
} 

i = 0; 
int Base10Value = 0; 
int Base10Count = count; 
printf ( "%i\n" , count ); 
for( count ; count >= 0 ; ) 
{ 
if ((65<=Val[i]<=90)or(97<=Val[i]<=122)); 
{ 
int BaseToPower = 1 ; 
for ( Base10Count ; ( Base10Count - 1 ) > 0 ; Base10Count-- ) 
{ 
BaseToPower *= Base; 
} 
if ( 65 <= Val[i] <= 90 ) 
{ 
Base10Value += ( ((Val[i] - 'A')+10) * BaseToPower); 
} 
if (Val[i]<= 97 ) 
{ 
Base10Value += ( ((Val[i] - 'a')+10) * BaseToPower); 
} 
count--; 
} 
if ( ( 48 <= Val[i] <= 57 )); 
{ 
int BaseToPower = 1 ; 
for ( Base10Count ; ( Base10Count - 1 ) > 0 ; Base10Count-- ) 
{ 
BaseToPower *= Base; 

} 
Base10Value += ( (Val[i] - '0') * BaseToPower); 
count--; 
} 
i++; 
}

-------------------------------- Report Message --------------------------------
Total errors (1)
Total warning (0)
Line 0 : Unmatched Curly brackets
--------------------------------------------------------------------------------
Elasped time: 0.0065 second(s)

[souldog]

My coding style preferences come after many, many years of coding and debugging (often other people's code). Over the years I have moved to a principle of coding in a style that is much more verbose. I add in 'superfluous' parentheses; I test explicitly for zero/non-zero rather that using the implicit conversion to bool + many other 'useless' things. I do all this (and wrote it into the coding style) because it all but eliminates most of the dumb mistakes people make. I've found that it's not a good idea to assume that has the same interpretation of 'obvious'.

Couldn't agree more. Always practice defensive coding style. I would much rather have "ugly" code, than waste time debugging trivial syntax errors.