Timeline for Why declare final variables inside methods?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Mar 13, 2019 at 14:40 | history | suggested | andrzej.szmukala | CC BY-SA 4.0 | fix link to Effective Java |
| Mar 13, 2019 at 7:34 | review | Suggested edits | |||
| S Mar 13, 2019 at 14:40 | |||||
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot | replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/ | |
| Feb 28, 2016 at 10:12 | comment | added | aioobe | The first half of your answer is only relevant to fields and is thus completely useless to this question. The whole "Minimize Mutability" section in Effective Java also talks about fields, so that reference is also useless here. This was pointed out in the first comment. Still you kept the entire answer intact and added some rambling about a complex if statement that seemingly doesn't have with final to do at all. I strongly encourage you to rewrite the answer so that it focuses on local variables. | |
| Aug 9, 2013 at 21:54 | comment | added | crazy2be | Personally, I would write your example something like int result = someFunctionWithComplexLogic(), and then allow the compiler to ensure that function always returns a value. This also often simplifies complex logic- your example becomes if (!/* something */) return 4; else if (/* something else */) return 1; else if (/* some other thing */) return 2;, which is much simplified from your original example. It's also trivial to see just by inspection (although the compiler will also verify it for you) that all of the cases are not handled. | |
| Feb 12, 2013 at 20:49 | comment | added | minopret | "Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis." -- Alan Perlis, "Epigrams in Programming", reproduced here: cs.yale.edu/quotes.html | |
| Dec 3, 2011 at 10:44 | comment | added | Jon | Good answer. Far more comprehensive than mine. I'd like to second the recommendation for "Effective Java", specifically the section on immutable objects, which is relevant to the discussion. | |
| Oct 25, 2011 at 12:23 | vote | accept | Rodrigo | ||
| Oct 25, 2011 at 12:24 | |||||
| Oct 23, 2011 at 16:43 | history | edited | user1249 | CC BY-SA 3.0 | added 126 characters in body |
| Oct 23, 2011 at 16:35 | history | edited | Joe Carnahan | CC BY-SA 3.0 | Explained the fact that final prevents you from getting into trouble with recycled variables |
| Oct 23, 2011 at 16:19 | comment | added | Joe Carnahan | The alternative to the code snippet that I had in mind isn't just the same code snippet with the word "final" removed. I'll edit my answer to make the alternative explicit. | |
| Oct 22, 2011 at 14:16 | comment | added | Peter Taylor | For one thing, uninitialized variables are no longer any concern, because trying to use a final variable before it has been initialized will result in a compile error. If removing the final keyword makes your example compile, you're using a defective compiler. Or, in other words, you've dedicated half of your post to a misleading statement. (If you wrote it in terms of a field rather than a variable then it would be a case where final makes a difference, but would become irrelevant to the question - just as your third point already largely is). | |
| Oct 22, 2011 at 11:40 | history | answered | Joe Carnahan | CC BY-SA 3.0 |