Timeline for Java Stack Implementation
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2017 at 8:20 | comment | added | Imus | On your unless explicitly documented: Code inside a method should normally be self documenting. If you see a method variable being reassigned, it should be clear why that is the case. | |
| Aug 3, 2017 at 8:18 | comment | added | Imus | I have never seen someone change a local variable inside a method by accident. And good coding practice suggest to not change method parameters in the first place (except maybe for handling default cases). That's also why I said you're not wrong for making those final, but I don't feel like it adds enough to enforce the use of final as "best practice" (in the scope of a method). | |
| Aug 3, 2017 at 7:24 | comment | added | SSC | @Imus What if by mistake, someone change the value of variable? Should a function not operate on the reference provided unless explicitly documented? | |
| Aug 3, 2017 at 7:22 | comment | added | Imus | I don't fully agree with your "make everything final" mentality. Not saying you're wrong but I feel java is already too verbose as is. So I wouldn't make method parameters or local method variables final. Especially if you follow good coding practices and have only a screenful of lines in that method (and thus you can clearly see at one glance that they don't get changed anyway). I do agree on making class variables final to show the intent of never changing them once created. | |
| Aug 2, 2017 at 17:09 | history | answered | SSC | CC BY-SA 3.0 |