1

This might sound like a dumb question, because it might be no other way to do this. After designing my own list, this sort of "issue" came up in multiple occasions. To clarify, I have a problem with returning a cached variable after assigning new value to the original variable. Here's an example:

public T next() {
            final Node<T> thisNode = posNode;
            posNode = posNode.getNext();
            return thisNode.getData();
        }

This might seem like a non-issue, but occasionally multiple variables has to be cached before returning a valid value. I do not really like it, because personally I think it reduces the code's readability, especially when caching multiple variables.

Is there another way to write this code while maintaining its functionality? Basically a way to assign a new value to a variable after the return statement:

public T next() {
            return posNode.getData();
            posNode = posNode.getNext();
        }

Thanks! :)

Snusifer
  • 485
  • 3
  • 17
  • 1
    What's wrong with the first way? – Federico klez Culloca Mar 14 '18 at 13:41
  • There is no way to do something like what you did in the second example. There is nothing wrong with the way you do it in the first example and it's done everywhere just like this. No reason to invent something new here. – Ben Mar 14 '18 at 13:42
  • Also if you personally feel like this reduces readability that is a totally valid standpoint to have. But imagine that: You invent some mechanism that does the second and now close to every Java developer who is used to the first example is majorly confused by your code. – Ben Mar 14 '18 at 13:44
  • 1
    What do you mean by _cached_? – Andrew S Mar 14 '18 at 13:44
  • @AndrewS He means "assigned to an intermediate variable to retain the value". – daniu Mar 14 '18 at 13:58
  • Second question if anyone wants to answer: So Iv'e been thinking, and thought I wish there was a better way to do this, I've came to the conclusion that the propper way to deal with this is naming the variables accordingly (see answer by Suresh Atta by naming them tempSomething). My question is, is there a way to program your own syntactic sugar? Maybe something like: return posNode.getData -> posNode = posNode.getNext(); – Snusifer Mar 14 '18 at 14:07
  • @Federico klez Culloca There is nothing inherently wrong with it. But it might occur that one have to cache multiple on multiple of variables before returning a valid value. I just think that having a block of cached items before you actually do something reduces the codes readability and elegancy. – Snusifer Mar 14 '18 at 14:12
  • @Snusifer regarding your "syntactic sugar" question, I think OldCurmudgeon's answer is what would get you closer to that. – Federico klez Culloca Mar 14 '18 at 14:17
  • @Ben Not necessarily. Implementing some sort of syntactic sugar that makes it *seem* like you are doing things after return statement (but in reality it just caches the items) lets you do things the old way, while also providing this new and exciting way to do this. Maybe something like: return posNode {posNode = posNode.getNext();}. Of course this is just a silly example, but I think something like this may even increase readability, because now you know exactly how the coder thinks. – Snusifer Mar 14 '18 at 14:26

3 Answers3

3

The second way is not possible as the code is not reachable after return. And your first way is the best way far you to achieve what you are looking for and it is not code smell. Often they refer as temp variables. Use them and better convey a message to the code reader by better naming convention. For ex tempPosNode

Suresh Atta
  • 120,458
  • 37
  • 198
  • 307
2

An elegant (but with some cognitive dissonance) option is a dummy method.

public static <T> T first(T first, Object... theRest) {
    return first;
}

public T next() {
    return first(posNode.getData(), posNode = posNode.getNext());
}
OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • It certainly answers the question and does what was asked. Also it's not really bad practice in my opinion. If I coworker did this I would probably be really confused and ask him why he did it this way but... it works and certainly is a better solution than wrapping your return in a try/finally. Maybe mention that this can theoretically be expanded for several dummy values as well as asked in the original question. Something like `was(T was, Object... is)` – Ben Mar 14 '18 at 14:02
0

You can use a finally block to execute it, but it will execute even after exceptions:

 public T next() {
      try {
        return posNode.getData();
      } finally {
        posNode = posNode.getNext();
      }
 }
Marcos Vasconcelos
  • 18,136
  • 30
  • 106
  • 167
  • 3
    Isn't this harder to understand? I mean, OP's example is pretty straightforward. I would scratch my head a bit seeing this instead. – Federico klez Culloca Mar 14 '18 at 13:52
  • Not really, since the actions must be taken after execution, I think its straight forward – Marcos Vasconcelos Mar 14 '18 at 13:56
  • While it does what was asked this is terribly bad practive to be honest. Have a look towards this question if you are thinking about doing this. https://stackoverflow.com/questions/48088/returning-from-a-finally-block-in-java – Ben Mar 14 '18 at 13:59
  • Also it's far from straight forward. It's incredibly confusing mostly because it's really hard to guess when what is executed if you haven't read up on it. This is as far from intuitive as you can get in my opinion. – Ben Mar 14 '18 at 14:03
  • The answer is differente form the question since it doesnt returns at the finally – Marcos Vasconcelos Mar 14 '18 at 14:07