7 ms·

Does it actually help? After 10 years of java I don't really remember any case where defining local variable as final would catch an error. Though maybe these c

• WHoWHo 9y ago
  From my experience in 20 years of Java, it prevents the reusage of local vars, which mostly is wrong. Person p = .... p = doSomething(p) ... p = doSomethingElse(p) is hard to reason about when it should be Person p = .... ... lots of code Person updated = doSomething(p) ... lots of code doSomethingElse(updated) Which is easier to read and understand. So you might have had bugs that would have been prevented with final, but you didn't attribute to final.
  • fauigerzigerk 9y ago
    I remember bugs that were caused by the exact opposite. If p is superceded by updated then it's not a good idea to have both hanging around in the local scope. You shouldn't be able to doSomethingElse(p) when you actually mean to doSomethingElse(updated).
    • Moter8 9y ago
      So basically, what rust prohibits.
      • fauigerzigerk 9y ago
        I don't know Rust very well at all, but I believe that Rust would only prohibit that if p and updated were referencing the same thing. If updated was a modified copy of p then I don't think Rust would help. But I could easily be wrong on that. What would help is splitting the function up so that you don't have multiple named variables representing multiple versions of the same thing in the same scope: Person doSomethingAndDots() { Person p = doSomething(...) ... return p } main() { doSomethingElse(doSomethingAndDots()) }
        • andrewaylett 9y ago
          If the transformation function consumes p, rather than taking a reference to it, Rust will stop you from using the variable again afterwards.
  • melling 9y ago
    I really like being able to declare immutable variables with ‘let’ in Swift. Java should add the immutable option too. Although, ‘val’ makes more sense considering Kotlin and Scala use it.
  • anon3474422 9y ago
    Rust explicitly allows shadowing, that way you can have it both ways. An immutable variable that can't be reassigned but you can still reuse names. That is to ease the pain of unwrapping nested types and error-checking intermediate steps so you don't have to come up with new names for each intermediate.
• mzl 9y ago
  For me, it is not about catching errors, it is about documentation. In the codebase I work on most, all variables that can be marked final are marked final. That means that whenever I see a non-final variable, I know that something tricky is happening and I need to be extra careful in reading the code.
  • chrislynch42 9y ago
    This is my reasoning as well. Also I am currently returning Optionals from any method that can result in a null.
    • derriz 9y ago
      The problem is that java.util.Optional has no special syntactic support compared to the way optionality is supported in Kotlin for example. And it is barely used in the standard libraries. And many/most 3rd parties libraries don't use it. Thus you end up with multiple styles in your code base: in places checking for null, in other places extracting the value from an Optional. And the type system/language doesn't prevent an Optional reference itself being null. The Optional class is typical of the halfassery that has accompanied many improvements to Java over the years. From java.util.logging to generics to streams, I'm invariably irritated by compromises particularly as they've decided that maintaining backward compatibility is now a secondary concern. I've run out of patience in the direction Java has taken and I've been a user since 1.0.4 - I'm going to try Kotlin for my next project.
      • cesarb 9y ago
        Also, if you're interoperating with Kotlin, a nullable reference works better than an Optional. A Kotlin nullable reference compiles down to a reference with intellij's @Nullable annotation, and a Kotlin non-nullable reference compiles down to a reference with intellij's @NotNull annotation. It also works in the opposite direction: a Java parameter or return value annotated as @Nullable (doesn't have to be intellij's, the Kotlin compiler understands several annotation libraries) will appear as a nullable reference to Kotlin code, and a @NotNull or @Nonnull annotation makes it appear as a non-nullable reference.