If you never ever worked with Java and coded in C, then it might be different. Typical Java programmer, even weak one, is fluent in Java 101, but does not really know what might confuse C programmer. In any case, I would expect C programmer finding job as Java programmer for some reason to simply ask someone in office.
I can't recall perfectly from the top of my head the rules for the ordering of inline side effects in general in C and Java, and I work in the VM research group at Oracle. Can you? Are you sure about that?
The ++ operator is not obscure at all and used more often then for example += operator.
I shy away from inline side effects because in general I do not intuitively understand how they sequence. I'd rather just avoid in general.
15.7, Evaluation Order:
> It is recommended that code not rely crucially on this specification. Code is usually clearer when each expression contains at most one side effect, as its outermost operation, and when code does not depend on exactly which exception arises as a consequence of the left-to-right evaluation of expressions.
So when I review I advise, as per the spec, that expressions contain a single side effect.
Edit:
You’ve completely changed your comment out from underneath me after I replied. That’s rude.
To answer your new question - you're not alone in not know what I mean by sequencing of side effects! Not many people understand the rules for sequencing side effects! That's my point it's subtle. The JVMLS gives you the rules, but it also says
> It is recommended that code not rely crucially on this specification. Code is usually clearer when each expression contains at most one side effect, as its outermost operation, and when code does not depend on exactly which exception arises as a consequence of the left-to-right evaluation of expressions.
I'm just following that advice!
For C it's worse - what order are two side effects run in a C expression? Usually the rule is 'it's up to the compiler - it can do them in any order it wants.'
What you need here is just knowing what "index++" means, nothing about sequencing at all.
I could understand your objection with the original version of the code, where it referred to both "i++" and "i" in a single line. That depends on sequencing rules and is a bad idea to allow.
But this version, that only refers to "index++" once, doesn't have any subtleties.
How do you explain your rule to a junior? You're going to have to tell them that inline side effects are fine, as long as you follow another set of rules about sequencing - a set of rules you admit most people don't know at all and fewer people understand correctly!
You don't need to know the sequencing at all. It doesn't matter.
My rule would be "If you side-effect a variable, don't use it anywhere else in the same line". I think that's plenty simple.
Edit: Another way of wording my rule would be "if you have to care about sequencing, don't do it"
Also, if the junior cant comprehend reasoning, he/she will have hard time with expressions like "inline side effects". The word inline is not much used in Java world.
If there is style guide, then it is different matter and the argument is about usefulness of style guide itself (e.g. you follow the rule unless rule harms, even if the rule is overly broad). Absent style guide, imposing your personal preferences on good lines, because entirely different line would be unreadable is not something I can support. I used to follow such instructions, but don't anymore because such blind follow tactic lead to all kinds of problems for me.
When I worked with juniors, I wanted them to understand so that they can make own decisions as soon as possible. I did not wanted them to memorize hundreds of random rules.
If you think brevity means clarity, try reading some old Fortran code with comments stripped out and single-letter variable names like i, j, k, b, g, h, m, p, q, etc. (I say Fortran because in that era, such variable names were much more in vogue to save a couple of bytes here and there - but really, this can be done in any language).
Even simple algorithms (like finding the center of the circle through three given points) become puzzles. But sure, they are brief.
[1]https://signalvnoise.com/posts/3250-clarity-over-brevity-in-...
In this case, though, the OP makes a strong point that constructs like data[index++] = value; aren't idiomatic to Java - even the spec advises against this.
And in any case, side effects in assignments can be a tricky thing to understand. Sometimes they are necessary, as in
status = perform_computation_on_data(some_mutable_data);
But in the example discussed is not in this vein. I'd say it's not pretty for the same reason as cramming two statements on one line: data[i]=value; i++;
is not pretty: it's trying to do two things with one line, which kind of defeats the point of breaking up code into lines.So I don't disagree with you - but there's a happy medium between Fizz Buzz Enterprise and Code Golf - style code :)