commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] Automated requirements (e.g. CheckStyle)?
Date Wed, 09 Aug 2017 02:57:11 GMT
On Tue, 8 Aug 2017 18:49:44 -0700, Chas Honton wrote:
> Since most of us work in an IDE, the "wasted" time of checkstyle for
> every build is negligible.

It's not just the wasted time of running the tool (which might
well be negligible), it's the forcing of e.g. documenting a code
that might turn out to be transient on the path to a complete
fix.

> At my day job, all code is automatically
> reformatted as part of the build. It's just another step along with
> PMD, CPD, findbugs, sonar, jacoco, junit, and a few other static
> analyses. The more we automate, the less we need to remember and the
> higher the quality of our code.

That's not always the case: I don't particularly like the "feature"
of IDEs that automatically inserts Javadoc templates:

/**
  *
  *
  * @param a
  * @param b
  * @return int
  */
public int doSomething(int a, int b) {
   // ...
}

Which then often remain useless as actual documentation. ;-)


Regards,
Gilles

>
> Chas
>
>> On Aug 8, 2017, at 4:13 PM, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>
>> Hello.
>>
>>> On Wed, 9 Aug 2017 00:20:00 +0200, Karl-Philipp Richter wrote:
>>> Hi,
>>>
>>>> Am 07.08.2017 um 15:09 schrieb Gilles:
>>>> Less work for the maintainers is good. :-)
>>>>
>>>> By "taking time" I meant that validating should not be enforced 
>>>> when
>>>> calling "mvn compile" or "mvn test".
>>> I wouldn't worry about the time consumption of the validation even 
>>> if
>>> it's run by every dev before very compilation since the sum of
>>> conversation parts in patch/PR discussion in the form of "LGTM, 
>>> except
>>> for the indentation at line xy" - "OK, I fixed that now" - "Oh, no 
>>> wait,
>>> I forgot the trailing space at line yz" - ... - merged takes an 
>>> infinite
>>> more of time and energy.
>>
>> I agree, but that is with respect to interaction with someone not 
>> used
>> to the coding style/rules; what I meant is that when doing one's 
>> "own"
>> work, one shouldn't have to wait for CheckStyle at every 
>> compilation,
>> when you know that you'll fix the missing doc _after_ fixing the 
>> code.
>>
>>> Regarding the phase where checkstyle should be run I have some
>>> additional thoughts to my initial post:
>>>
>>>  * If running checkstyle will be enforced the only phase that makes
>>> sense is `validate` because you don't won't to build something 
>>> that's
>>> invalid because it's somehow unlogical and a waiste of time if you 
>>> don't
>>> fail the build as early as possible. In order to avoid annoyance 
>>> for
>>> users who aren't used to fix checkstyle errors before being able to
>>> build I'd suggest a profile with deactivated checkstyle which 
>>> allows
>>> that rather an putting checkstyle in a separate profile.
>>
>> IIUC, that would be fine (since it takes care of the above 
>> scenario).
>>
>>>  * Running checkstyle in the site or any other reporting phase is 
>>> in
>>> Maven speak afaik "show what might be wrong with my build given the 
>>> fact
>>> that I consider it passing after compilation, unit and integration 
>>> tests
>>> passed" or "show me some statistics about style issues - 150, wow 
>>> that's
>>> 12 less than last build".
>>
>> That's what we've done up to now; and the number of errors is 
>> supposed
>> to be zero before a release.  But I agree that the risk of a lot of 
>> work
>> for the RM would be reduced by enforcing checks at least before 
>> committing
>> to the "master" branch.
>>
>> Is anyone objecting?
>>
>> I think that the profile should be defined in the "parent" POM.
>> Can someone make the necessary additions?
>>
>> Thanks,
>> Gilles
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message