«

Eric Sosman wrote:
> Big K wrote:
> > Eric Sosman wrote:
> >
> >>Gregory Dean wrote:
> >>
> >>>On 1/31/05 10:20 AM, in article
> >
> > ctlic0$ffm$, "Eric
> >
> >>>Sosman" <> wrote:
> >>>
> >>>
> >>>
> >>>>Luke Wu wrote:
> >>>>
> >>>>
> >>>>>I personally would never nest ternary : ? opeartors like this
> >>>>>(especially never putting the whole thing inside a printf
> >
> > argument!).
> >
> >>>>>If statements are less error prone and in this case, there
really
> >
> > is no
> >
> >>>>>reason to use operators (count the difference in number of
> >>>>>lines???).
> >>>>
> >>>> State your preference:
> >>>>
> >>>>hand_type = is_straight
> >>>> ? is_flush ? STRAIGHT_FLUSH : STRAIGHT
> >>>> : is_flush ? FLUSH : NOTHING;
> >>>>
> >>>>vs.
> >>>>
> >>>>if (is_straight) {
> >>>> if (is_flush) {
> >>>> hand_type = STRAIGHT_FLUSH;
> >>>> }
> >>>> else {
> >>>> hand_type = STRAIGHT;
> >>>> }
> >>>>}
> >>>>else {
> >>>> if (is_flush) {
> >>>> hand_type = FLUSH;
> >>>> }
> >>>> else {
> >>>> hand_type = NOTHING;
> >>>> }
> >>>>}
> >>>>
> >>>>Neither is "righter" or "wronger" than the other, and
> >>>>both clarity and beauty lie in the eye of the beholder.
> >>>>Still, to my eye the first is preferable.
> >
> > Yes, they are both "right," but the question is whether or not
people
> > "accept" a method as being clear. In the real world, we don't keep
our
> > code to ourselves (only in the fake world we do that), we share it
and
> > allow others to understand it. I am pretty sure the people who
find
> > the IF STATEMENTS "appropriate" are a superset of the ones that
find
> > the nested CONDITIONALS "appropriate." In a software engineering
> > team, it's better to aim for the superset.
> >
> > If you're only coding alongside seasoned veterans, without any
junior
> > programmers, then the two sets are probably the same and you will
have
> > no problem.
>
> If we eliminate from C all the things some people find
> confusing, what will remain? The traffic in this newsgroup
> shows that people are confused by arrays, by pointers, by
> floating-point arithmetic, by much of <stdio.h> (printf()
> makes lots of trouble, scanf() even more), by all of <ctype.h>,
> by structs, by functions with prototypes, by functions without
> prototypes, by variable-length argument lists, and by main().
>
We're talking about two different ways to do the same thing by an
actual developer (read original post), not about the mistakes made by
people learning the language. I guess the DEEP TERNARY NESTING vs.
MULTILEVEL IF is just a difference of opinion, let's leave it at that.
>
> Purging C of all these (and of the many other confusions
> I haven't listed; these are off-the-top-of-my head topics)
> would leave a language that might be named "C minus" but would
> certainly not merit so high a mark ...
>
Once again, this is not a discussion about "purging" ternary operators
from the language and forcing developers to use IF statemetns. We're
talking about a solution to a problem (presented by the original
poster), that can be solved by NESTED TERNARIES or MULTILEVEL IF
statements. Nobody is talking about removing actual features from the
language. If you read the original post, you will see that the
individual was "at first glance" confused by the use of nested
ternaries. He also mentioned that certain tools his company used
couldn't recognize the nested ternaries, while it recognized the
multilevel IFs. I don't know where you go the idea that I wanted to
"purge" features from the language. Ternaries are awesome, but their
use in deep nesting can cause problems to less experienced developers,
optimizers, debuggers, complexity analyzers, etc (which was the subject
of the original post- have a look).

I am not bashing ternary operators or you're use of them. You probably
use it in a much clearer way than in the code the OP encountered,
which is fine.
>
> >>>Debugging is much easier in the latter. Try to set a breakpoint
on
> >
> > the
> >
> >>>ternary version.
> >>
> >> (1) No problem, if you'll let me choose a debugger
> >>that can set breakpoints at arbitrary machine instructions.
> >
> > Do you have the luxury of choosing IDEs where you work? What if
someone
> > else wrote the code and tested it for an IDE that doesn't offer the
> > features that you want? So your debugger has to conform to your
code,
> > instead of your code being more universally debuggable?
Source-level
> > debugging doesn't guarantee anything about machine instructions
> > (AFAIK).
>
> Are you arguing that debuggers should not have capabilities
> not shared by all other debuggers? That is, that there should
> be just one Ur-debugger?
>
No, but if you read the concerns of the OP, you will notice that his
tools had trouble recognizing the ternary conditionals AND he was
dealing with code developed by someone else. If you have a really
awesome debugger that lets you set machine level breakpoints while
stepping through source level code, then I guess this is a non-issue.
>
> >> (2) Try to set a breakpoint in the latter form, after
> >>an optimizing compiler has transmogrified the code and
> >>generated the same instructions as for the former form.
> >
> > You are assuming that the ternary form doesn't need optimizing and
that
> > the IF form, when optimized, produces the same code as the ternary
form
> > (and otherwize creates more machine instructions).
>
> No; I'm assuming that some compiler somewhere might generate
> the same code for both forms.
>
Then what did you mean by this comment:
---
(2) Try to set a breakpoint in the latter form [with IFs], after
an optimizing compiler has transmogrified the code and
generated the same instructions as for the former form.
---
If you meant that a compiler somewhere might generate the same code for
both forms, then how does your comment above (2) support nested
ternaries?
[Not insulting, I am just confused]


>
> > In fact, a friend of
> > mine who is a compiler writer told me that compilers he has written
> > would optimize the IF's better than the deeply nested ternaries.
>
> Strange; the latter should be easier. For starters,
> there's only one assignment target, hence no need to "notice"
> that the four targets in the `if' form are in fact the same.
>
Different of opinion among different people. Let's leave it there.
>
> Perhaps your friend may have been referring to code like
>
> #define max2(a,b) ((a) > (b) ? (a) : (b))
> #define max4(a,b,c,d) max2(max2((a),(b)), \
> max2((c),(d)))
>
> ... which I would most definitely not recommend; the apparent
> simplicity conceals a surprisingly voluminous expansion, with
> lots of common sub-expressions a compiler might need to struggle
> to eliminate.
>
Nope, wasn't referring to that.
>
> > You can always turn optimization off to debug a section of code you
> > know will be heavily optimized.
>
> ... at which point you are no longer debugging the actual code,
> but a sort of proxy for it. I've debugged plenty of problems
> that only showed up after optimization, that is, problems that
> simply vanished when optimization was turned down or off. "Test
> what you fly; fly what you test."
>
I was responding to your comment (2). A compiler is free to optimize
either form, so I had no clue what your comment (2) was trying to
convey. Of course you should turn optimization on again after you have
found the fault with the debugger (that's if you had to resort to
turning it off in the first place, which is always a last-hope method).
NASA's mantra "test what you fly; fly waht you test" is posted above
the whiteboard beside me. But what is wrong with doing intermediate
tests on proxies to find a fault, then doing thorough tests on the real
thing afterwards?
>
> >> (3) Debugging is inferior to inspection, in the sense
> >>that a debugger can (at best) show you things that have
> >>actually happened, while inspection can drive assertions
> >>about all the things that can and cannot happen.
> >
> > You are comparing apples to organges. People don't pick debugging
OVER
> > inspection or vice versa. The two happen at different phases and
deal
> > with different problems. We should code to best satisfy all phases
of
> > development/debugging, not one over the other.
>
> Different development activities have different goals and
> are sometimes in conflict. It is not always possible to "best
> satisfy" all of them; compromises are required.
>
> However, I'll still maintain that it's better to be able
> to prove things about a section of code than to run a bunch
> of test cases through it and say "Well, nothing broke. Yet."
>

Code inspections don't catch all bugs, neither does debugging. There is
no "better" method. You try to catch bugs as early as possible, and
you make every phase in the development cycle as robust as possible-
you can't make compromises. Everything must be taken seriously, there
are no preferences.

>
> >>I feel
> >>that the former is easier to inspect than the latter, hence
> >>easier to prove things about, hence less likely have bugs
> >>in the first place!
>

Difference of opinion. But realize that you can't rely solely on code
inspections.

> >
> > IF statements are better for code inspections than DEEPLY NESTED
> > conditional ternaries.
>
> Proof by assertion. (You're in good company; Edsger W.
> Dijkstra did a lot of important work, but is probably best
> known for just such a proof.)
>
Proof? It's an opinion that was a response to your opinion.
>
> > IF statements allow for braces to surround
> > different blocks that correspond to different conditions. Say if
you
> > use extended bracing, you can draw lines from the top brace of
every
> > block to the bottom brace of every block (in coloured pencils or
> > visually). This give so much more visibility than nested ternary
> > operators.
>
> If you feel like it, you can do the same with ternaries:
>
> hand_type
> = is_flush
> ? is_straight
> ? STRAIGHT_FLUSH
> : FLUSH
> : is_straight
> ? STRAIGHT
> : NOTHING;
>
> ... and you can even throw in a few levels of parentheses if
> you want them.
>
Difference of opinion.
>
> > I like how you made the IF statements look overly expensive(with
> > brackets) while making the ternary statements look very clean in
your
> > presentation above.
>
> Observation #1: Didn't you just get through saying
> you *liked* all those braces?
>
I like extended braces (read my comments again).
>
> Observation #2: Did you just describe the ternary
> formulation as "very clean?" My point, exactly.
>
>
I said "look very clean" in the superficial sense. That says nothing
about how easy it is to understand the code, or how well tools can
deal with it.
>
> >> (4) Debuggers are like crutches: When you need them
> >>you do in fact need them, but you will never progress as
> >>well as when you can do without them.
> >
> > I see, so you're that famous programmer I read about in magazines
that
> > never needed debuggers. That means you're a PERFECT software
engineer
> > and a very LUCKY software engineer that only ran into code written
by
> > other PERFECT software engineers.
>
> Excuse me, but what justifies this insult? Did I not say
> that "When you need them you do in fact need them?" Yes, I
> did. Did I claim perfection? No, I did not. Back off.
>
Read (4) again. It was in response to another poster and the OP who
were obviously concerned about debuggers and other tools. In (4) it
"sounded" like you were saying that people who "needed" debuggers were
inferior somehow. Maybe I took it the wrong way, but then again, you
did take my joke as an "insult" too.
>
> > I might be guilty of the same. I see no problem in the ternary
> > conditionals, but I work with a lot of beginner programmers
(hardware
> > guys who are programming for the sake of controlling their
hardware),
> > so for me the "superset" has far more members than the "subset."
>
> Clarity of expression is not achieved through baby talk.
>
Clarity is not measured in lines of code, and isn't the only important
facet of software development (even though I think the IFs are more
clear). If you are referring to the fact that some programmers make
their code extra "babyish" to allow beginners to understand it, then
what's wrong with that? Like you said, the two methods can be optimized
to the same machine instructions, so why not make the code extra
"clear" to the people who are most likely to trip over it? Tools matter
too, and OP obviously had some issues with the nested ternaries. Let's
leave opinions out of it, and concentrate on the issues the OP had.
Deal?
>
> --
>

There is no reason to continue this discussion, since opinions are just
that, opinions (I appologize for trying to assert my opinion).