Bad Programming Language Features

[DaleDoe]

Jerry wrote:

IAMJWC is correct about the use of END - not every statement, just at the end of blocks of code.

OK.  That makes a bit more sense.  Unless I'm misunderstanding, C++ uses a '}' at the end of a block of code, not a ';'.  And I still disagree; I think '}'s are quicker to type and more readable than "end".

[Jerry]

DaleDoe wrote:

OK.  That makes a bit more sense.  Unless I'm misunderstanding, C++ uses a '}' at the end of a block of code, not a ';'.  And I still disagree; I think '}'s are quicker to type and more readable than "end".

Yep, but part of the problem that programmers, particularly new programmers, have are disambiguating the use of the statement terminator ';'.

For example, here is a typical piece of code I see from new programmers working in IC6:

   

Code Select Expand

if (! a_button());
           motor(1,50);

Means something different than

Code Select Expand

if (! a_button())
           motor(1,50);

But they do not understand or simple miss the fact that they put a ';' after the if condition.

Instead, this could make it more clear:

Code Select Expand

if (! a_button())
           motor(1,50);
       endIf

A typical activity in robotics is to have the robot wait until a particular button is hit. This would make it clear that the meaning is "While the a_button is not touched do nothing"

Code Select Expand

while (! a_button) endWhile
      motor(1,50);

Even if you teach programming habits of always using code block deliminters '{}', programmers can spend time having to match these up properly. Specific "endWhile, endIf, endFunction, ..." would make these clearer. Not to mention the problems that can happen when they leave them off of a loop or conditional construct when it contains only a single executable statement.

As for saving time typing - well context specific editors can reduce typing. It would be interesting to know if they reduce the number of programming errors too.

Though I have to wonder if DaleDoe is naming all of his variables with a single character to save time typing  ;-)

[William Grim]

I don't think placing the constant on the left-hand side makes it any more difficult to read code; I think the equality operator should make the intent perfectly clear.  However, that's a style issue and always up for debate; I just like it because the benefit far outweighs any cost of spending an extra split-second thinking about it.

As for your function, I don't know if I'd do that.  It adds more confusion than a simple reordering of the values to compare, but if you are going to do it, a macro would be best:

Code Select Expand


#ifndef EQUALITY
#define EQUALITY(x,y) x == y
#else
#error EQUALITY already defined.
#endif


With the above macro, you've eliminated any performance hit, and it works with any data type.

[sparks]

As for your function, I don't know if I'd do that. It adds more confusion than a simple reordering of the values to compare, but if you are going to do it, a macro would be best:

I disagree strongly that the function adds confusion.  That is the beauty of choosing meaningful names.  When you read the if statement, it makes sense logically.  In fact, someone not familiar with the syntax of C could read that if statement and perhaps figure out the intent.

Code Select Expand

#ifndef EQUALITY
#define EQUALITY(x,y) x == y
#else
#error EQUALITY already defined.
#endif


I like the benefit of this macro--works on any type that can be compared; no performance hit.  However, because it works on any type, it's not as error-proof as the functions I discussed.

For example:

Code Select Expand


if(EQUALITY(1, 'a')) [i]do something...[/i]


wont complain but...

Code Select Expand


if(areEqualInts(1, 'a')) [i]do something...[/i]


will most certainly complain, so it takes away the chance of making a mistake of this nature.  And performance is certainly a consideration, but I'll let my performance profiler tell me if there is an issue.

Again, I guess it comes down to personal style, taste, and preference.

[William Grim]

Code Select Expand


if(areEqualInts(1, 'a')) do something...


will not complain except for a warning if full warnings are enabled (and they should be).  The compiler will just promote the character data type to an integer and pad the upper N-8 bits with zeroes.  Likewise, if I pass a float or a double, a similar thing will happen (they will be truncated).

So, again, the functions don't make much sense.  I see what you're trying to do (and it's a good idea), but adding X functions for what you want adds much more confusion than reversing the order of comparisons in an equality test.  The brain gets used to seeing patterns, and "==" is a pattern that is quickly recognized when it's the only pattern used for an equality.  The extra functions are going to incur extra overhead for no added benefit that I can see.

As a side note, I think -pedantic on GCC compilers will cause GCC to stop with an error if it reaches something like

Code Select Expand


if ('a' == 1)

but allow it to continue if it encounters

Code Select Expand


if ('a' == (const char)1)

The reason for this is because -pedantic (I am pretty sure that's the option) will make GCC follow type checking rules religiously.