code generation for the ternary operator

[Roedy Green]

I wonder if anyone has ever looked at the byte code and/or the hotspot
code generated by code like this:

final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;

vs:

int count = lines *3;
if ( b1 ) count += 2;
if ( b2 ) count += 2;

I wondered how clever it is. This is just curiosity. This is not
critical code.

Which style do you prefer?
--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 

[Jaap Droogers]

I wonder if anyone has ever looked at the byte code and/or the hotspot
code generated by code like this:

final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;

vs:

int count = lines *3;
if ( b1 ) count += 2;
if ( b2 ) count += 2;

I wondered how clever it is. This is just curiosity. This is not
critical code.

Which style do you prefer?

The second: clean code!
I don't like code that I don't understand at the first glance.
Always use curly brackets:

int count = lines *3;
if ( b1 ) {
count += 2;
}
if ( b2 ) {
count += 2;
}

Don't try to do the optimizing work for the JIT compiler, she can handle
it herself very good.

Jaap Droogers

 

[Henk van Voorthuijsen]

I wonder if anyone has ever looked at the byte code and/or the hotspot
code generated by code like this:

final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;

vs:

int count = lines *3;
if ( b1 ) count += 2;
if ( b2 ) count += 2;

I wondered how clever it is.  This is just curiosity. This is not
critical code.

I prefer a third option:

int count = lines * 3;
count += b1 ? 2 : 0;
count += b2 ? 2 : 0;

Henk van Voorthuijsen

 

[markspace]

Always use curly brackets:

I prefer Roedy's version here, it's easier to read. Never say never,
and never say always. You can omit braces when they reduce code
readability.

 

[Andreas Leitgeb]

I prefer a third option:
int count = lines * 3;
count += b1 ? 2 : 0;
count += b2 ? 2 : 0;

I put forward an (N+1)st variant:

int b1Contrib = 0, b2Contrib = 0;
if (b1) { b1Contrib = 2; }
if (b2) { b2Contrib = 2; }
int count = lines * 3 + b1Contrib + b2Contrib;

doesn't look too exciting, but maybe would more so, if
b1Contrib and b2Contrib were renamed to something really
meaningful.

 

[Daniel Pitts]

I wonder if anyone has ever looked at the byte code and/or the hotspot
code generated by code like this:

final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;

vs:

int count = lines *3;
if ( b1 ) count += 2;
if ( b2 ) count += 2;

I wondered how clever it is. This is just curiosity. This is not
critical code.

Which style do you prefer?

If you're going for terseness or obscurity:

final int count = lines * 3 + b1 != b2 ? 2 : b1 ? 4 : 0;

 

[Daniele Futtorovic]

If you're going for terseness or obscurity:

final int count = lines * 3 + b1 != b2 ? 2 : b1 ? 4 : 0;

'!=' is ugly for booleans. Make that a '^' and we have a winner.

 

[Lew]

schreef Roedy Green:

The second: clean code!
I don't like code that I don't understand at the first glance.
Always use curly brackets:

If you don't understand the ternary operator at first glance, the programming world should not use you as the bellwether of readability.

int count = lines *3;
if ( b1 ) {
count += 2;
}
if ( b2 ) {
count += 2;
}

Don't try to do the optimizing work for the JIT compiler, she can handle
it herself very good.

Good advice.

 

[Lew]

I personally don't care for the byte code unless it really matters,
which is almost certainly never. So I concentrate on readability and
code style.
Among these two, I'd prefer the first variant for these reasons:
It is obviously very clear that the value "count" won't change later in
the program. It's short, concise and the brackets look like a "capsule"
that wraps the decision being made.
But if the term is getting too long, it might be a good idea to write
this, which I find even more readable:

final int v1 = b1 ? 2 : 0;
final int v2 = b2 ? 2 : 0;
final int count = lines * 3 + v1 + v2 ;

Still I would try to find proper names for "v1", "v2", "b1" and "b2",
like for example:

final int optionalHeader = headerPrinted ? 2 : 0;
final int optionalFooter = footerPrinted ? 2 : 0;
final int count = lines * 3 + optionalFooter + optionalHeader;

+1

to all of the above.

I'm immersed in style guidance these days, and that is some of the best style guidance I've seen.

 

[Michal Kleczek]

I wonder if anyone has ever looked at the byte code and/or the hotspot
code generated by code like this:

final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;

vs:

int count = lines *3;
if ( b1 ) count += 2;
if ( b2 ) count += 2;

They are not equivalent.

Which style do you prefer?

Contrary to most here I really like ternary conditional operator because
of this little "final" modifier you have to omit in the second case.

 

[Owen Jacobson]

I prefer Roedy's version here, it's easier to read. Never say never,
and never say always. You can omit braces when they reduce code
readability.

Having spent some time in languages with poor IDE support, I'd weaken
that: you can omit braces, when they reduce code readability, if the
language or its tools permits easy mechanical reformatting. While the
Java ecosystem has some good code formatters, not every language is so
fortunate.

I've come to miss having a machine tell me if my formatting really
matches my semantics, now that I don't have that on a daily basis.

-o

 

[Roedy Green]

Having spent some time in languages with poor IDE support, I'd weaken
that: you can omit braces, when they reduce code readability, if the
language or its tools permits easy mechanical reformatting. While the
Java ecosystem has some good code formatters, not every language is so
fortunate.

In SCID thinking the brackets are LOGICALLY there, but whether they
are currently VISIBLE, is something you set as an option. It is
rather egotistical of other programmers to force me to read code their
way. (I am for {} all the time in real code. I just stripped them
from that example for brevity.)

see http://mindprod.com/project/scid.html

I could imagine some people displaying code with no { } at all, except
perhaps for loop and methods, showing structure purely by indentation.
For scanning code, you want to get hide clutter, perhaps even
arithmetic or other housekeeping.
..

--
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things.
We understand human mental processes only slightly better than
a fish understands swimming.
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence),
the short-circuit OR operator (|| in Java),
and LISP (LIst Processing Language) that makes EMACS
(Extensible MACro System) so addictive.

 

[Daniel Pitts]

In SCID thinking the brackets are LOGICALLY there, but whether they
are currently VISIBLE, is something you set as an option. It is
rather egotistical of other programmers to force me to read code their
way. (I am for {} all the time in real code. I just stripped them
from that example for brevity.)

see http://mindprod.com/project/scid.html

I could imagine some people displaying code with no { } at all, except
perhaps for loop and methods, showing structure purely by indentation.
For scanning code, you want to get hide clutter, perhaps even
arithmetic or other housekeeping.
..

I've often thought about a "new" way of representing code, where the
logical structure is stored in not-necessarily-human-editable format,
but the tools for managing the code allow it to be presented in a format
chosen by the particular maintainer.

In other words, you have the language constructs (classes, methods,
fields, statements, aspects, loops, etc...) modeled, and then have view
in front of that model which make them "look" like something that can be
manipulated easily by the programmer.

I would imagine such a system has a bit of ramp-up time, but it would
eventually allow you to be much more productive. The "concrete" manor
that the object model stores things would allow you to refactor very easily.

 

[Daniel Pitts]

On 11/1/2011 9:41 AM, Daniel Pitts wrote:
....

I think one of the more difficult problems would be adjusting revision
control systems, including diff and merge programs. They would
themselves presumably work on the abstract representation, but have to
present their results in the programmer's view.

Patricia

I agree, I had thought the exact same thing actually ;-)

 

[Gene Wirchenko]

On Tue, 01 Nov 2011 09:41:00 -0700, Daniel Pitts

[snip]

I've often thought about a "new" way of representing code, where the
logical structure is stored in not-necessarily-human-editable format,
but the tools for managing the code allow it to be presented in a format
chosen by the particular maintainer.

One problem is whether you can replicate my way. I like my code
formatted a certain way. If your tool can not do this, I will not
like using it. I will avoid it if at all possible.

Other people feel the same way about their formats. Miss very
many possibilities, and you will have bad will from [|potential]
users.

I was wading through the editor settings for Visual Studio and
ended up having to shut off a lot of the formatting, because the
formatting done was not to my taste.

I was just looking through the editor settings for Dreamweaver.

In other words, you have the language constructs (classes, methods,
fields, statements, aspects, loops, etc...) modeled, and then have view
in front of that model which make them "look" like something that can be
manipulated easily by the programmer.

A loop already can be manipulated easily by a competent
programmer.

I would imagine such a system has a bit of ramp-up time, but it would
eventually allow you to be much more productive. The "concrete" manor

^^^^^^^^^^ ^^^^^
Or it would be a straitjacket.

I do not understand the captioned words as used. Should "manor"
be "manner"?

that the object model stores things would allow you to refactor very easily.

How would you deal with the case of syntax errors? I sometimes
have a placeholder. A simple example would be:
i=0;
while (i<SomeValue*****)
{
<various looping statements>
}
The point is that I might not know exactly what the looping condition
has to be. (In this case, I might be wondering if I will need a flag
for early exit.) I want to able to enter a placeholder should I need
it.

VB 6 had a switch for compiling each line as entered. I did not
like it and disabled it as part of my configuration. Sometimes, in
mid-line, I would note that I had to change something else. When the
option was enabled, I would move off the line and often get a syntax
error. I knew that. I prefer to be told about compilation errors
when I ask, not to be interrupted by an overeager compiler.

Sincerely,

Gene Wirchenko

 

[Roedy Green]

In other words, you have the language constructs (classes, methods,
fields, statements, aspects, loops, etc...) modeled, and then have view
in front of that model which make them "look" like something that can be
manipulated easily by the programmer.

I have been pushing the SCID idea for decades. There has been very
strong resistance to it. I think it is based on the following:

1. I talk about all the wild an crazy things you COULD do with code
display it if were pre-parsed into a tree. Most of these things
remind people of the clownish decor in a McDonald's restaurant. They
imagine garish colours, dancing paperclips, animated icons... And run
in horror. They don't get in that what I am about is CUSTOMISATION,
so you can have the display EXACTLY the way YOU like it, completely
independent of what other people like. None of this would be
mandatory. They look at my prototype JDisplay listings and recoil at
the garishness. http://mindprod.com/jgloss/jdisplay.html

2. People have SCID-like tools that just got in the way of editing.

3. People like the security of text files. Database have a habit of
losing everything, perhaps with software is discontinued, OSes
changes.

4. Experienced programmers think of programming as manipulating text.
They have to be weaned to think more of thinking of programming as
more like plumbing where you interconnect names. Eventually editing
will be much more visual where you select methods, drag variables into
place, and do a lot of selecting from a list of what the SCID
considers most plausible.

I have been pitching some of these ideas to IntelliJ. I am using the
notion of almost-subliminal differences in the way text is rendered to
give additional information about each symbol without having to look
back at the definition. Given that you are not supposed to even
notice the difference perhaps contrarians will then argue for more
distinctive warping.
--
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things.
We understand human mental processes only slightly better than
a fish understands swimming.
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence),
the short-circuit OR operator (|| in Java),
and LISP (LIst Processing Language) that makes EMACS
(Extensible MACro System) so addictive.

 

[Roedy Green]

I think one of the more difficult problems would be adjusting revision
control systems, including diff and merge programs.

Circa 1995 I proposed a new way of doing version control that would
interface with SCIDs that keeps you more up to date on what other
programmers are up to. See
http://mindprod.com/project/dynamicversioncontrol.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things.
We understand human mental processes only slightly better than
a fish understands swimming.
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence),
the short-circuit OR operator (|| in Java),
and LISP (LIst Processing Language) that makes EMACS
(Extensible MACro System) so addictive.

 

[Roedy Green]

One problem is whether you can replicate my way. I like my code
formatted a certain way. If your tool can not do this, I will not
like using it. I will avoid it if at all possible.

I have three problems with that way of thinking.

1. if you are in a team environment, you have to use a common tidier
to avoid false deltas. You can tidy it to whatever you want to edit,
but you must tidy it back to corporate standard before checkin. You
can't expect others to follow your formatting rules not part of what
the corporate formatter does. I worked in a place before the days of
formatters and each programmer thought he "owned" some of the code and
formatted it in a unique way, and fights broke out over variations.
Part of the problem came because some programmers had big screen and
others tiny ones. The big screen programmers wanted long lines, the
others short.

2. Surely you would not reject an IDE just because its formatter did
not do precisely what you wanted. So why reject a SCID? You would
export code for presentation to some formatter of your own that did
the touch-ups. Surely in an IDE you would not maintain your coding
conventions manually. Would you?

3. that is only one factor. The SCID would give you overwhelming
advantages to compensate for that loss, which is aesthetic, not so
much productive.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and
faster each year, but the focus on money makes software manufacturers
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore
ignored. The manufacturer focuses on cheap gimicks like dancing paper
clips to dazzle naive first-time buyers. The needs of existing
experienced users are almost irrelevant. I see software rental as the
best remedy.

 

[Lew]

Daniel Pitts wrote:

[snip]

I've often thought about a "new" way of representing code, where the
logical structure is stored in not-necessarily-human-editable format,
but the tools for managing the code allow it to be presented in a format
chosen by the particular maintainer.

One problem is whether you can replicate my way. I like my code
formatted a certain way. If your tool can not do this, I will not
like using it. I will avoid it if at all possible.

Other people feel the same way about their formats. Miss very
many possibilities, and you will have bad will from [|potential]
users.

I was wading through the editor settings for Visual Studio and
ended up having to shut off a lot of the formatting, because the
formatting done was not to my taste.

I was just looking through the editor settings for Dreamweaver.
It does not do what I want. <sigh>

For workaday programmers, house style is also an issue. Whatever your particular preference, at work you have to put the braces and indentation wherethe boss says to. (Ah, I see Roedy made the same point.)

But prettifiers exist and are quite common and highly customizable. Some shops take advantage of this, letting programmers goof up on style a little and cleaning it up on the way in to the VCS.

Regardless, I don't know that there is an intermediate format to store source code that improves upon, well, source code. The usual intermediate format is object code. Decompilers certainly exist and work well.

As for your particular predilection to store invalid code in source, well, that's just bad practice. Oh, not while it's sitting in your editor or IDE, but that use case doesn't call for an intermediate format. The one that could, were it not for the aforementioned superiority of simply storing thedamn source, what's the big effing deal?, is when you share the code, at which point you certainly won't want non-syntactic code going forth. DBTB - Don't Break The Build!

 

[Gene Wirchenko]

I have three problems with that way of thinking.

1. if you are in a team environment, you have to use a common tidier
to avoid false deltas. You can tidy it to whatever you want to edit,
but you must tidy it back to corporate standard before checkin. You
can't expect others to follow your formatting rules not part of what
the corporate formatter does. I worked in a place before the days of
formatters and each programmer thought he "owned" some of the code and
formatted it in a unique way, and fights broke out over variations.
Part of the problem came because some programmers had big screen and
others tiny ones. The big screen programmers wanted long lines, the
others short.

Straw man. An obvious extension of my argument is that the team
might have a format that they wish to keep, and the tool does not
allow for it.

2. Surely you would not reject an IDE just because its formatter did
not do precisely what you wanted. So why reject a SCID? You would

I might if the offness were severe enough.

Why? If it does not do what I want.

export code for presentation to some formatter of your own that did
the touch-ups. Surely in an IDE you would not maintain your coding
conventions manually. Would you?

Actually, I do. IOW, yes, I do follow my conventions.

3. that is only one factor. The SCID would give you overwhelming
advantages to compensate for that loss, which is aesthetic, not so
much productive.

I have heard that argument too many times. The advantages are
often not really so overwhelming and come with disadvantages that do
not get much mention. I am not buying into something until I am
reasonably sure that it actually will be a benefit.

Sincerely,

Gene Wirchenko