Are Some Programming Languages More Aspie than Others?

Post Reply New Topic

I'm not talking about making up constants (or macros) to compare. I'm talking about using predefined constants based on the documentation of a function. If a function is defined as returning 0 for failure and non-zero for success, you should only compare the result to 0. Not TRUE or FALSE or S_OK or some other constant you've come up with. If the docs say to compare it with TRUE or FALSE, then do so.

I would also suggest that programmers writing functions define and return constants rather than things like "!TRUE" or "!FALSE". In many ways I like the HRESULT that COM uses. It has defined constants for success and failure conditions and defined macros for determining what a particular value means. It's also extendable so that programmers can add their own values.



We'll just have to disagree on this one. I think it makes the intent of the programmer clearer and can reduce bugs.

You have a boolean data type, and you have a expression "E" which is boolean, and you wish to use it, in a place that syntactically requires a boolean, and instead of putting just "E", you replace that with the null effect construct "E == true" (or maybe "E != false"?).

Do you do the same with arguments to function calls? Assignments?

Why do so in "if" statements?

Do you also write "if ((x > y) == true)"?

Choose your variable names carefully, and your code is intelligible.

I don't think you can explain your point clearer than that. Argument over.

What docs are you talking about exactly? If you are talking about some software docs, that is a bit naive. You need to know what the possible return values might be more like.

I'm talking about documentation that comes with functions you didn't write. I'm talking about development on a large scale where you might not have access to the source code of the functions you're calling. How else would you know how to interpret the return values of a function if it's not documented? How is this naive? Do you go through the machine code provided by other developers to figure out what they are doing rather than referring to documentation?



No, I don't write that. If you read my previous posts you'd know I write it as


[/sarcasm]

Seriously, I get that you guys don't see the difference between that and my other examples. I chalk it up to differences of opinion. Deal with it. You're not going to convince me to change.

i'm not sure what the [/sarcasm] is for.

There is no syntactic difference between what I showed and your examples.

There is a semantic difference, in that your example, where you chose to exchange the two expressions supplied to the equality operator, one of those expressions happened to be a direct reference to a variable.

I actually do find the defensive code form "if (<constant> == <expression>)" to be occasionally useful. However, your compiler switches should be set to warn about the (probably accidental) usage "if (<variable> = <expression>)".

In fact, I often use that sort of semantic form, on purpose, and the compiler is happy to accept it when I show it was intentional, by writing it as "if ((<variable> = <expression>))".

Generally, though, using "if (<constant> == <expression>)" often obscures the meaning and the layout of code. It is not similar to normal speech. "if (MyApple == Red)" looks fine. "if (Red == MyApple)" is just silly.

To go back from C/C++ specifics to programming languages. This problem is special C/C++ problem. Languages which are based on Algol (Pascal, Ada, Modula) do not have the problem:



An assignment is always ":=" and is not allow in an expression to evaluate, so a typcial C-Expression like:



in Algol and Algol-based languages this would need to have the following form:


There are also other differences, that logical operators are written as logical operators:




The typical C/C++ typo of "&" "|" (bitwise) and "&&" "||" (boolean) can not happen!
---

In my option this programming languages based on Algol are here much better, because they separate clear the call of function (procedure) and evaluation of an expression and the assignment of data. In this respect C and C++ was a huge step backwards to lift this clear separation and allow potential error, which are only shown via compiler warnings.

Algol doesn't make function calls separate. They are constituents of expressions, just the same as just about all languages.

It is such a stilted coding technique: separating every function call onto its own line, with a temporary variable being assigned the result.

Also, accepting that an assignment is just another form of binary operator has always seemed far more natural to me. It was started in Algol and Coral, both of which allow multiple LHS assignment variables. C merely took their lead and improved on the idea. Pascal was more awkward, and took the form of a variable list, separated with commas, as the LHS of an assignment.

(I'm pretty sure that the Algol68 syntax covered everything that went into C, and far, far more. I've lost my copy of the Algol 68 report. I used to spend hours reading it.)

You are right - I had to look up, also for Pascal (it is a while ago I wrote the last time in Pascal and I confused the programming style I was trained with the actual standard.

The main different here remains that Algol and Pascal do not allow assigment in boolean expressions, quite sensitive.

Nonesense they should tell you what the function does not what statements to write, that is your job.

I think people are getting confused over the assignment and not focussing on the fact there is an unnecessary comparison being made.

If you do not wish to call the function more than once then assignment makes sense, but you still don't have to compare against true/false if the function returns a bool. Besides in many instances you can remodel your logic so it is one statement.

I guess I can best explain that I prefer my conditional statements to have some sort of comparison operator in them. I don't write (x > y) == true or the reverse as they already have a comparison operator. You seem to think that's confusing (along with flipping constants and expressions in conditionals) and I don't.



Please supply a quote of me where I said I expect function writers to document the statements I should write or do my job. I said:



Are you going to answer the question or just throw back another nonrelated statement?

So... assuming that we are talking C here, you are saying that documentation that baldly tells you that you must compare a return value to FALSE when you are aware that the value defined for FALSE is 1,315,926,085 is good documentation for a well designed system that will be bug free?

If such a situation did exist (which it does, from time to time), the documentation should be riddled with cautions explaining why the design is flying in the face of the language's defined truth values.

ah but it returns a value, just like a function can

You could have a function like IsGreaterThan(x,y). If you use an OO language '>' is a method of x which takes y. You could just as well substitute 'isGreaterThan?' for the method.

Whether it is a method, or construct doesn't matter it is there in order to retun a value. If you already have a return value there is no need to compare it to true/false.


You didn't understand my response or else you would not be asking that.

It is not their job to tell you what you should be comparing. It is their job to tell you what the possible return values are.

If I was given a library which internally defined FALSE to something other than 0, I probably would not use it. Or if I had to, I'd #define NAMEOFTHELIB_FALSE to whatever they use and use that in my code.

Lau, is this really the best example you can come up with to refute what I wrote? In the situation you describe, if there's no source code to identify the unconventional definition of FALSE - then yes, I'm going to follow the documentation on my initial run at the problem. Obviously the code won't work - I'll have to debug and identify the actual return values of the function and change my code to deal with it or move to a different library that behaves as it is documented. I don't understand how I would be "aware" of the unusual definition of FALSE without doing this or reading the machine code.



I didn't say there was a need to compare it. I said I prefer the syntax. Do you understand the concept that someone could prefer something you do not?



I fail to understand how you think they are different. Perhaps you can elaborate. In my mind, telling me the return values of a function also tells me what I should be comparing the result to.

Yes I understand you prefer (true==true) to true, suit yourself.



It assumes that you are going to compare it to anything. true is understood, it needen't be compared to true