Re: [Discussion] Improving Spotless to be Even More Beautiful
On Tue, Mar 20, 2018 at 9:06 AM, Patrick Rhomberg wrote: > > @Galen, I had thought it already did that. > I guess it does. I never knew. Excellent!
Re: [Discussion] Improving Spotless to be Even More Beautiful
Glad to see a positive response! @Galen, I had thought it already did that. On Mon, Mar 19, 2018 at 4:52 PM, Galen O'Sullivan wrote: > +1 to all of the above. > > Will Spotless also reorder imports according to our canonical ordering? > > On Mon, Mar 19, 2018 at 4:17 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > +1 > > > > On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund wrote: > > > > > +1 > > > > > > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg < > prhomb...@pivotal.io> > > > wrote: > > > > > > > Hello all! > > > > > > > > I'm making another pass at patching up some of our smellier broken > > > > windows, to mix metaphors. To that end, there are a few things I'd > > like > > > to > > > > add to spotless to more closely enforce adherence to our own style > > guide. > > > > > > > > I'd like to do the following to our spotless: > > > > - Bump spotless to the newest version, enabling some of the features > > > below > > > > - Have spotless only run spotless on files that have changed (Yay, > > > slightly > > > > faster builds!) > > > > - Have spotless perform the following spotless tasks: > > > > --- Remove unused imports. > > > > --- Prohibit wildcard imports, which may require manual expansion by > > the > > > > developer. (But, in fairness, you shouldn't be using wildcard > imports > > > > anyway.) > > > > --- Remove trivial javadoc stubs that are implicit in the method > > > signature > > > > (e.g., "@param p" with no description of what p actually is). > > > > --- Remove empty javadocs and block comments. > > > > > > > > This will again touch a great many files, so it should be targeted > for > > > > immediately following a release, perhaps the impending 1.5. It can > > > pretty > > > > easily be exploded into several commits across each subproject and > task > > > for > > > > ease of review. > > > > > > > > Thoughts? > > > > > > > > Imagination is Change. > > > > ~Patrick Rhomberg > > > > > > > > > >
Re: [Discussion] Improving Spotless to be Even More Beautiful
+1 On 3/19/18 2:51 PM, Patrick Rhomberg wrote: Hello all! I'm making another pass at patching up some of our smellier broken windows, to mix metaphors. To that end, there are a few things I'd like to add to spotless to more closely enforce adherence to our own style guide. I'd like to do the following to our spotless: - Bump spotless to the newest version, enabling some of the features below - Have spotless only run spotless on files that have changed (Yay, slightly faster builds!) - Have spotless perform the following spotless tasks: --- Remove unused imports. --- Prohibit wildcard imports, which may require manual expansion by the developer. (But, in fairness, you shouldn't be using wildcard imports anyway.) --- Remove trivial javadoc stubs that are implicit in the method signature (e.g., "@param p" with no description of what p actually is). --- Remove empty javadocs and block comments. This will again touch a great many files, so it should be targeted for immediately following a release, perhaps the impending 1.5. It can pretty easily be exploded into several commits across each subproject and task for ease of review. Thoughts? Imagination is Change. ~Patrick Rhomberg
Re: [Discussion] Improving Spotless to be Even More Beautiful
+1 to all of the above. Will Spotless also reorder imports according to our canonical ordering? On Mon, Mar 19, 2018 at 4:17 PM, Sai Boorlagadda wrote: > +1 > > On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund wrote: > > > +1 > > > > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg > > wrote: > > > > > Hello all! > > > > > > I'm making another pass at patching up some of our smellier broken > > > windows, to mix metaphors. To that end, there are a few things I'd > like > > to > > > add to spotless to more closely enforce adherence to our own style > guide. > > > > > > I'd like to do the following to our spotless: > > > - Bump spotless to the newest version, enabling some of the features > > below > > > - Have spotless only run spotless on files that have changed (Yay, > > slightly > > > faster builds!) > > > - Have spotless perform the following spotless tasks: > > > --- Remove unused imports. > > > --- Prohibit wildcard imports, which may require manual expansion by > the > > > developer. (But, in fairness, you shouldn't be using wildcard imports > > > anyway.) > > > --- Remove trivial javadoc stubs that are implicit in the method > > signature > > > (e.g., "@param p" with no description of what p actually is). > > > --- Remove empty javadocs and block comments. > > > > > > This will again touch a great many files, so it should be targeted for > > > immediately following a release, perhaps the impending 1.5. It can > > pretty > > > easily be exploded into several commits across each subproject and task > > for > > > ease of review. > > > > > > Thoughts? > > > > > > Imagination is Change. > > > ~Patrick Rhomberg > > > > > >
Re: [Discussion] Improving Spotless to be Even More Beautiful
+1 On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund wrote: > +1 > > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg > wrote: > > > Hello all! > > > > I'm making another pass at patching up some of our smellier broken > > windows, to mix metaphors. To that end, there are a few things I'd like > to > > add to spotless to more closely enforce adherence to our own style guide. > > > > I'd like to do the following to our spotless: > > - Bump spotless to the newest version, enabling some of the features > below > > - Have spotless only run spotless on files that have changed (Yay, > slightly > > faster builds!) > > - Have spotless perform the following spotless tasks: > > --- Remove unused imports. > > --- Prohibit wildcard imports, which may require manual expansion by the > > developer. (But, in fairness, you shouldn't be using wildcard imports > > anyway.) > > --- Remove trivial javadoc stubs that are implicit in the method > signature > > (e.g., "@param p" with no description of what p actually is). > > --- Remove empty javadocs and block comments. > > > > This will again touch a great many files, so it should be targeted for > > immediately following a release, perhaps the impending 1.5. It can > pretty > > easily be exploded into several commits across each subproject and task > for > > ease of review. > > > > Thoughts? > > > > Imagination is Change. > > ~Patrick Rhomberg > > >
Re: [Discussion] Improving Spotless to be Even More Beautiful
+1 On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg wrote: > Hello all! > > I'm making another pass at patching up some of our smellier broken > windows, to mix metaphors. To that end, there are a few things I'd like to > add to spotless to more closely enforce adherence to our own style guide. > > I'd like to do the following to our spotless: > - Bump spotless to the newest version, enabling some of the features below > - Have spotless only run spotless on files that have changed (Yay, slightly > faster builds!) > - Have spotless perform the following spotless tasks: > --- Remove unused imports. > --- Prohibit wildcard imports, which may require manual expansion by the > developer. (But, in fairness, you shouldn't be using wildcard imports > anyway.) > --- Remove trivial javadoc stubs that are implicit in the method signature > (e.g., "@param p" with no description of what p actually is). > --- Remove empty javadocs and block comments. > > This will again touch a great many files, so it should be targeted for > immediately following a release, perhaps the impending 1.5. It can pretty > easily be exploded into several commits across each subproject and task for > ease of review. > > Thoughts? > > Imagination is Change. > ~Patrick Rhomberg >
Re: [Discussion] Improving Spotless to be Even More Beautiful
+1 to all of the above On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg wrote: > Hello all! > > I'm making another pass at patching up some of our smellier broken > windows, to mix metaphors. To that end, there are a few things I'd like to > add to spotless to more closely enforce adherence to our own style guide. > > I'd like to do the following to our spotless: > - Bump spotless to the newest version, enabling some of the features below > - Have spotless only run spotless on files that have changed (Yay, slightly > faster builds!) > - Have spotless perform the following spotless tasks: > --- Remove unused imports. > --- Prohibit wildcard imports, which may require manual expansion by the > developer. (But, in fairness, you shouldn't be using wildcard imports > anyway.) > --- Remove trivial javadoc stubs that are implicit in the method signature > (e.g., "@param p" with no description of what p actually is). > --- Remove empty javadocs and block comments. > > This will again touch a great many files, so it should be targeted for > immediately following a release, perhaps the impending 1.5. It can pretty > easily be exploded into several commits across each subproject and task for > ease of review. > > Thoughts? > > Imagination is Change. > ~Patrick Rhomberg >
[Discussion] Improving Spotless to be Even More Beautiful
Hello all! I'm making another pass at patching up some of our smellier broken windows, to mix metaphors. To that end, there are a few things I'd like to add to spotless to more closely enforce adherence to our own style guide. I'd like to do the following to our spotless: - Bump spotless to the newest version, enabling some of the features below - Have spotless only run spotless on files that have changed (Yay, slightly faster builds!) - Have spotless perform the following spotless tasks: --- Remove unused imports. --- Prohibit wildcard imports, which may require manual expansion by the developer. (But, in fairness, you shouldn't be using wildcard imports anyway.) --- Remove trivial javadoc stubs that are implicit in the method signature (e.g., "@param p" with no description of what p actually is). --- Remove empty javadocs and block comments. This will again touch a great many files, so it should be targeted for immediately following a release, perhaps the impending 1.5. It can pretty easily be exploded into several commits across each subproject and task for ease of review. Thoughts? Imagination is Change. ~Patrick Rhomberg
