Am 27.10.2014 um 02:04 schrieb Gary Gregory: > On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <oliver.he...@oliver-heger.de> > wrote: > >> >> >> Am 24.10.2014 um 22:47 schrieb Mark Thomas: >>> On 24/10/2014 21:17, Oliver Heger wrote: >>>> >>>> >>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory: >>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger < >> oliver.he...@oliver-heger.de> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory: >>>>>>> Patches go stale no matter what... >>>>>> >>>>>> Right, this can happen during normal development, but not necessarily >>>>>> because of a big bang change for which there is no technical reason, >> but >>>>>> which is just a matter of personal taste. >>>>>> >>>>> >>>>> I call it a technical reason, you call it personal taste, we are not >> going >>>>> to agree. >>>> >>>> Obviously not. So how do we proceed? >>> >>> You work it out until a consensus is reached and then that consensus is >>> implemented. The more entrenched folks are in their positions, the >>> longer consensus is going to take. (And no, a VOTE is not the right way >>> to resolve this.) >>> >>> My own view is that the addition of the final keywords does have >>> technical merit. Not enough to make me want to spend the time to fix the >>> projects I work on, but I wouldn't complain if someone else wanted to >>> make all the necessary changes. Similarly while I think it would be a >>> shame to throw away all this good work, I could live with that option if >>> that was the consensus opinion. >>> >>> The issue of out-dated patches is a red herring. That is a separate >>> problem. The community needs to apply / review patches faster. >>> >>> Mark >> >> Okay, so back to discussion. >> >> First of all I have to state that I am irritated about the way this >> change was done. It is really an invasive commit without any prior >> announcement. For a collaborative project I do not consider this as good >> style. As some replies to this thread show, there is no consensus about >> the changes performed. >> >> As an example on the same level, > > > This is a silly example IMO because you talk about using a Windows C > _naming_ convention in Java, which has zero effect on compiled code, while > we are talking about using a Java language feature which does matter to the > compiler. Apples and Oranges.
Not in the sense that both changes aim at making code more understandable without having any impact on functionality. > > >> I could come to the idea that I prefer >> variable names with special prefixes. In C programming under Windows >> there was a convention of adding prefixes to variable names derived from >> their data type: String sName, int iCount, Double[] adNumbers, etc. What >> could argue that this makes code more understandable because each >> variable carries meta-information with it. If I suddenly started to >> rework the code of multiple components based on this convention, I would >> surely trigger some reactions. >> >> IIUC, the purpose behind this change is to make the intension of the >> programmer explicit that a specific variable is not going to be changed. >> > > It is that, and more. Just as important and perhaps more so: When I read > code or I am stepping in a debugger and I see a 'final' I know that a value > is not going to change from under my feet. I can put that aside as a > variable (pun intended) in my mind and worry about other aspects of the > code. The vast majority of Java code I encounter does not use final modifiers in this way (I know, it is your mission to change this). Therefore, when I see a final I ask myself what is the special purpose here? Is it referenced by an anonymous class? The information whether a variable cannot be changed has not been that important for me; this can easily be spotted from the context: if there is an assignment, well it is changed. Otherwise, your method is probably too complex and needs refactoring. Oliver > > Gary > > >> I doubt that you manually inspected the whole code base. Rather, I >> assume you used a tool - Eclipse has a corresponding option - which >> analyzed all possible code paths to determine whether a variable can be >> final. This does not tell too much about the intentions of the original >> authors. Further, when using such a tool there is not much intellectual >> work behind this. Please correct me if I am wrong here. >> >> From my perspective the excessive use of final modifiers makes code >> harder to read because it adds so much noise. There are some places when >> Java requires the use of final; but those special places which may be of >> interest are now completely hidden in the overall final fog. >> >> Oliver >> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
