4 ms·

I’m not really sure what you mean by “the rules for the ordering of inline side effects”. I think they’re usually relatively simple to understand, such as with

by r-w 8y ago

I’m not really sure what you mean by “the rules for the ordering of inline side effects”. I think they’re usually relatively simple to understand, such as with postfix and prefix incrementation operators; but I’m sure there are other cases I’m not aware of. Care to expand on these?

chrisseaton 8y ago
Is everyone deliberately ignoring the bit where I said I was talking about inline side effects and how they sequence in general and how it wasn’t about this specific code? Inline side effects are subtle and confusing. Best to avoid in general in my opinion. 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.'
- Dylan16807 8y ago
  The ordering/sequencing of side effects is not the problem here. It doesn't matter at all whether index updates before data, or data updates before index. Few people know, and even fewer need to know. 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.
  - chrisseaton 8y ago
    My rule is really simple to explain to a junior - "don't use any inline side effects." 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!
    - Dylan16807 8y ago
      I guess I was unclear. 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"
    - watwut 8y ago
      I use rules I can defend. Be defense, I mean can explain impact on readability or maintainability - personal preferences dont count. E.g., if I have to use "I don't like it" then it is bad rule. Also, I deal with code in question, not with imaginary different code. This particular line is plenty readable and maintainable. People typically don't know about X is argument, but then people really typically must make mistakes about X. This is shared industry standard is an argument, but again, then is must really be industry habit. Not just me wanting it to be so. 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.

by r-w 8y ago

chrisseaton 8y ago

Is everyone deliberately ignoring the bit where I said I was talking about inline side effects and how they sequence in general and how it wasn’t about this specific code? Inline side effects are subtle and confusing. Best to avoid in general in my opinion. 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.'

Dylan16807 8y ago
The ordering/sequencing of side effects is not the problem here. It doesn't matter at all whether index updates before data, or data updates before index. Few people know, and even fewer need to know. 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.
- chrisseaton 8y ago
  My rule is really simple to explain to a junior - "don't use any inline side effects." 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!
  - Dylan16807 8y ago
    I guess I was unclear. 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"
  - watwut 8y ago
    I use rules I can defend. Be defense, I mean can explain impact on readability or maintainability - personal preferences dont count. E.g., if I have to use "I don't like it" then it is bad rule. Also, I deal with code in question, not with imaginary different code. This particular line is plenty readable and maintainable. People typically don't know about X is argument, but then people really typically must make mistakes about X. This is shared industry standard is an argument, but again, then is must really be industry habit. Not just me wanting it to be so. 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.