Code consistency vs using new features

So, lets say you added a new feature to an existing Java project, and when adding unit test you see that other similar tests are using null checks:

if(value != null){
    assertEquals("Value should be 10", 10, value);
}

But you know about Optionals so your test could look like:

Optional.ofNullable(value).ifPresent(value ->
    assertEquals("Value should be 10", 10, value)
);

Another example could be type annotations in Python

Which is more important to you? Keep the code consistent but not using new features or use new features even if code will end up looking inconsistent?

Only considering that using or not using new features is not a decision based on performance, security or any other concern

My initial approach would be keep it consistent but add a low priority task to refactor code if/when necessary, but curious to find out what others think.

Comments

[Alain Van Hout]

When adding or changing code of any kind, predictability and mental load always come into play. That's no different when we're talking about either using a new language feature or sticking to the older language features that are typically used in the piece of code you're working with.

You need to ask yourself:

Does using the new language feature decrease predictability and/or increase mental load for the next developer that will work on this code?

If that's not the case, then using the new language feature does no harm (i.e. all else being equal, it's fine to use the new language feature).

Do note though that reduced mental load is not the same as
(1) being a cool new feature
(2) requiring less code/characters

As an obvious example of the first, the above change from using an if block to using Optional does increase mental load, because you're essentially writing an if statement in a roundabout rather than a straightforward way.

An example of the second, using an actually if-else statement is typically more transparent and requires less mental load than an inline conditional, despite the latter requiring less characters to write:

if (x) {
  doA();
} else {
  doB();
}

x ? doA() : doB()

[Elliot Derhay]

And once again, the answer is "it depends".

[Josh Cheek]

In general, I'd rather use a useful feature than keep writing things in a confusing or tedious old style. However, the "consistent" example here is much better than the "new feature" example. However, the example doesn't really make sense: why would the test not know the expected result? Eg if it should be 10, then it shouldn't be null, presumably only one of these is the correct behaviour. And in the case of a test like that, if the pattern was showing up often enough to talk about consistency, then, I'd make a helper function to encapsulate all the duplication.

[Miguel Teheran]

I work with C# and it has many features regarding version 7, 7.1, 7.2. I try to use all new features always when I have to make a new code but I avoid to update or make a refactoring in code already working fine.

Finally, the code is gonna be strange because you have some pieces different than the original but using the new features make you a better developer in the time.

[Chuck Ha]

I like to make sure everyone on the team supporting the codebase is on the same page. Once we all agree that yes, we want to use the new feature then we can incrementally improve the code. I would not use the new feature until that first step is taken because inconsistency when you're not expecting it can be pretty confusing.

If it's just me coding, I'll use it because it's probably a side project and I want all the new things~~