There are tens of possible types of changes here, each affecting tens or even 100+ files. I wondered if it would be irritating to open, potentially, tens of JIRAs.
Maybe I can start with a JIRA or two, each addressing one or a few closely-related changes. If it's going well, I can propose more until it's clear we're getting too fine-grained. I'll do this over time since some changes will affect the same files or sections of code. On Sat, Nov 2, 2013 at 3:03 PM, Gilles <gil...@harfang.homelinux.org> wrote: > On Sat, 2 Nov 2013 14:52:34 +0000, Sean Owen wrote: >> >> In Math, is there any appetite for large patches containing many >> instances of particular micro-optimizations? Examples: >> >> - Replace: >> a[i][j] = a[i][j] + foo; >> with: >> a[i][j] += foo; >> … which is faster/leaner in the byte code by a little bit. It might >> make a difference in many nested, tight loops. >> - Inefficient toArray() calls with 0-length arg >> - Using Map.entrySet() instead of keySet() + get()s >> - Unnecessarily non-static private methods/classes >> - StringBuffer vs StringBuilder >> - etc. >> >> There are some non-functional but still possibly useful, simplifying >> changes too: >> >> - Add @Deprecated annotations >> - Fix broken method refs in javadoc >> - Removing unnecessary boxing/unboxing >> - Using foreach where possible >> - etc. >> >> I could go on for a while. Most of what I might otherwise suggest is >> style-level stuff like fixing C-style array declarations which is >> unlikely to be useful enough to justify. Or, it would involve changing >> signatures somewhere, which is probably not cool. >> >> If there’s interest in these sorts of things I can generate one or >> more patches easily. The downside is the disruption of large patches, >> perhaps breaking existing patches. > > > I think that is good to have a uniform style. > But why would a big patch be unavoidable? Reviewing a few changes is easier. > > Thanks for your help with this, > Gilles > > > [1] If just for better readability. But not the majority shares this view > around here. > > > > --------------------------------------------------------------------- > 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
