Are Some Programming Languages More Aspie than Others?

Post Reply New Topic

none, stop proje4cting

Odd. I find I have to quote myself, t0, as you seem to have invented a great number of excuses in order to avoid answering the question I posed.

Ok, lets start over. I'm still unclear as to one issue: Where is the value for FALSE defined to be 1,315,926,085? In the default headers that come with my compiler, my existing project, or in the new library I'm trying to use? Is FALSE defined with a different value in either of the other two (perhaps with a different name or small enough scope as to not conflict)?

OK. So you don't want to answer.

I base my judgement on the "goodness" of the documentation based on its accuracy. If the documentation says that a function returns FALSE and that the library uses a nonstandard for FALSE, then I would say the documentation is good for the library. Poor design choice, but the documentation is accurate.

Your question refers to "good documentation for a well designed system". I don't think this would qualify as a well designed system. As I posted earlier, a better-designed system would use macros that do not conflict with language defaults (MYLIB_FALSE) rather than ones that do.

Did that answer your question? If not, what in particular do you feel that I dodged?

Your assertion was that, "If the docs say to compare it with TRUE or FALSE, then do so". You subsequently said that you would not do this. You would ignore the "docs", define your own constant and use that instead.

You now also say: "I don't think this would qualify as a well designed system." However, I doubt that you have examined my choice of constant. It may well be a perfectly valid and well designed system. The fact that you don't find it so, on a cursory look, is of no consequence.

==============

You did not answer the question, again. You stopped short before "... that will be bug free?"

I would give a simple answer to my question: "No".

I too, would not slavishly follow the documentation. I would try to get the documentation changed, to make it far less obscure.

It is obviously misleading to use a name for a constant when that name is already (frequently, but not always) defined as something else.

Following the documentation, to the extent of "If the docs say to compare it with TRUE or FALSE, then do so" is just wrong. This is telling you how to write your code. It is not telling you what your code should do. If you were to follow the documentation, in this case, it would leave any subsequent maintainer with a far greater task understanding the code.

Relabelling the constant as "MYLIB_FALSE" (and why should this be YOUR LIB?) is of utterly no use. You are still preserving the documentation's poor utility. Whoever produced the documentation was not being helpful. They have merely written some shaky, misleading pseudo-C code, rather than anything useful. Such documentation is normally found when it has been written AFTER the coding. Typically, in these cases, there has been no design stage at all.

============

As for whether the code will be bug-free (my question, which you didn't answer) - of course, the chances are good that the code will be bug-full. No design, bad documentation, mindless coding. The net result is code that appears to do one thing, when it actually does something completely different.

When I see "if (!thing()) { ... }", I have utterly no need to refer elsewhere, to be confident of exactly what is being done. There is a truth value being returned by the function call, and if it indicates falsehood, the following statement is executed.

Seeing some code that says "if (FALSE == thing()) { ... }", which is what you originally stated you would write, should the documentation tell you to do so, fails on so many levels. Not least, because the reader of the code would assume FALSE had its conventional value/meaning.

If I were to see "if (MYLIB_FALSE == thing()) { ... }", which is what you now state you would write, I would be alerted to the fact that something might be going on. However, it conveys nothing more than the fact that you seem to have decided to define your own constant, for some reason known only to yourself. It is of no use in terms of understanding what the code might be doing. It required the reader to look elsewhere, in some place that you have chosen to tuck away your redefinition. Maybe there they will find "#define MYLIB_FALSE JIMSINCS_FALSE"... and in Jim's files, they will find "#define JIMSINCS_FALSE ARTHURSDEFINES_FALSE", etc.

Now, seeing "if (thing() == PackedASCII_Nope) { ... }" might be a little better, although I'd seriously question a design that resulted in this being a sensible way to do things... except, sometimes this might be exactly valid. Watermarking locations can be useful as a very quick sanity check.

No, I don't think it would be bug free.

I'm going to skip your criticism of my solution - I think it's a rather pointless discussion when I've only written a few sentences to briefly describe it rather than typing the full answer that I have in my head. I doubt it would be of interest to anyone else anyway.

I will take away from this discussion:
1) Badly designed code causes bugs. (What a shock)
2) You can make general rules about how to write code, but badly designed code may force you to break your rules and come up with a different solution. (another shocker)

You seem to have introduced a new concept.