Are Some Programming Languages More Aspie than Others?

Post Reply New Topic

Comments.

Lack of.

You seem to be acknowledging that your code fragment is unintelligible, unless it it read in the context of 1,500 other lines of code.

OK. I'm being brutal. However, I cannot stress the value of meaningful comments, as opposed to obscuring white space, enough.

Precisely how a piece of code does its work is rarely of any interest. Once it is working, it may never need to be looked at again.

If your comments say broadly what the code is intended to do, with maybe some justification for the algorithm chosen, and what any more obscure data is doing, then that should enable the maintainer to skip past the body with some confidence that that is what the code actually does.

In a sense, you are right.

I am complaining about comparing boolean for equality to boolean to get a boolean result. Say it like that, and it sounds pretty obscure, no?

Dussel has misnamed his function, in my mind. His function is called "DoSomething", but that does not properly convey what it is.

It should be named more like "DoSomthingWorkedOK", as it is returning a boolean to indicate its success.

Hence I believe the code should read as:
if (DoSomethingWorkedOK()) { DoTheNextBitOfStuff(); ... }

Choosing to compare the perfectly good boolean return value to a boolean constant, it then would read as:
if (DoSomethingWorkedOK() == true) { DoTheNextBitOfStuff(); ... }

I'd say that the former conveys exactly what is happening. The later is just stilted computerese.

When I am in a object-oriented context the really important part is the definition of the public methods. How I do handle internally in my class the results (as a vector-template, as a array, as I do, or else) is not of real interest, when the class has been set up properly. as class of mine has often not more than 10 public methods, and anything which reminds on data is private.

BTW: This is small project for my hobby. When I write in professional environment, I write an external documentation in which I go into detail how and why I did something and discuss in length the arguments in favour and against certain solutions or provide lengthy tables with possible values, return values and cross-references. Such documentation easily reached some 100s pages of small print and grow normally out of the design notices I collect during the development. When I write code for my own I remember very well what I wrote and why I wrote it.

So why offer up a code fragment that you knew would be unintelligible, as if it exemplified good practice, maintainable code?

I thought it was obvious that the necessary check-up, control flows etc. would be already done and that the not-declared variables are members of the class. One of the main benefits of object-orientation is to hide such functionalities and protect ("private") those from any call from outside the class (even this concept is in C++ a bit weak - "friend"/"protected"); it was just outside my mind that anyone even would think about this.

Therefore I was surprised about your comments, even I see now, why you raised those.

No. Tying such qualities to programming languages does not make sense

C++ Java or other OOPs could be consitered aspieish due to the fact they are dealing with spesific types of atributes of programing...

It makes sense: If you ever debugged the 10th complex list in C in a program when any pointer-stew raised you happy to have a cover or even a template which you need to establish just ones.

I think I prefer to compare the results of functions (even in the case where they return boolen values) as a defensive programming mechanism. If someone else changes the function to return a different type and misses one or more of the references, hopefully my compiler will generator a warning indicating such.

Yes - the condition in an "if" is required to be boolean (in any sensible language). I prefer to make it boolean, rather than have an error reported.

The problem with a language that does NOT require a condition to be a true boolean type, is that people introduce horribly difficult bugs, by doing what you suggest:



This, where SillyCFunction is perfectly within its rights to return zero for false, and any other value for true. That is what a conditional will test for, by definition of the language.

Arbitrarily adding a layer of text that you feel "looks better" is just making the code more verbose, less clear, and prone to an additional set of bugs.

The only valid way of coding the above sort of C thing would be:
I still wouldn't use the above.

If I really have to have a FALSE constant, and even a TRUE one, I will use:

which is as language portable as it can be.

With "real live" projects you often have to include headers (and libraries) from other projects. I found, especially if pure C-headers are included (or legacy code, slightly covered in classes), stuff like:



If you can't rewrite the old code, you are better off with an explicit check.

Technically, the above "#define" for "true" is correct. K&R does indeed specify that the value of a boolean test, assigned to a variable, will be zero, for false, and unity, for true.

I prefer the ruby way, it makes sense, and you don't use silly functions/statements to see if something is 'empty' or set. 0 evaluates true being from numerical class and meaningful in that form, just like the string '0' would evaluate to true. Only nil and false evaluate to false.

0 was invented by the Babylonians as a placeholder in their early positional number system. The Indians expanded on this in their arithmetic. What it means it dependent on context. Equating it to nil is not always appropriate.

Nil is not the same as undefined in other languages. Nil signifies emptiness. Whereas undefined means it hasn’t been defined.

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.