On Mon, Aug 11, 2014 at 8:06 AM, Joshua Partlow <
joshua.part...@puppetlabs.com> wrote:
>
>
> On Sunday, August 10, 2014, Rahul Gopinath wrote:
> > Here is a related issue,
> >
> > I notice that there are different conventions for spacing followed
> > when using method calls with parenthesis,
> >
On 2014-08-11 17:06, Joshua Partlow wrote:
On Sunday, August 10, 2014, Rahul Gopinath mailto:ra...@puppetlabs.com>> wrote:
> Here is a related issue,
>
> I notice that there are different conventions for spacing followed
> when using method calls with parenthesis,
> including `method(a,b)`, `me
On Sunday, August 10, 2014, Rahul Gopinath wrote:
> Here is a related issue,
>
> I notice that there are different conventions for spacing followed
> when using method calls with parenthesis,
> including `method(a,b)`, `method( a, b )` and `method( a,b )`. Does
> the list have a preference for one
Would it make sense to add such a cop also? -- i.e A cop that bans
method calls (with at least one argument) without parenthesis
(We don't have one right now, but I think it can be done easily)
On Fri, Aug 8, 2014 at 3:13 PM, Andy Parker wrote:
> On Fri, Aug 8, 2014 at 3:11 PM, Rahul Gopinath w
On Fri, Aug 8, 2014 at 3:11 PM, Rahul Gopinath wrote:
> While correcting AndOr, I come across methods calls such as `if
> value.is_a? FixNum or value.is_a? Integer`
>
> How should we parenthesize it? is it `(value.is_a? FixNum) ||
> (value.is_a? Integer)` or should it be `value.is_a?(FixNum) ||
While correcting AndOr, I come across methods calls such as `if
value.is_a? FixNum or value.is_a? Integer`
How should we parenthesize it? is it `(value.is_a? FixNum) ||
(value.is_a? Integer)` or should it be `value.is_a?(FixNum) ||
value.is_a?(Integer)` ?
(The question is specific to boolean pr
On Thu, Aug 7, 2014 at 6:09 PM, Rahul Gopinath wrote:
> While hacking rubocop, I found that I can get it to autocorrect even
> more `Style/AndOr` violations if I replace the use of the `not`
> keyword with `!` first. The Rubocop is able to do the necessary
> changes automatically. So I think we s
While hacking rubocop, I found that I can get it to autocorrect even
more `Style/AndOr` violations if I replace the use of the `not`
keyword with `!` first. The Rubocop is able to do the necessary
changes automatically. So I think we should turn on the `Style/Not`
cop also for our code for three re
On Wed, Aug 6, 2014 at 5:39 PM, Kylo Ginsberg wrote:
> On Tue, Aug 5, 2014 at 3:50 PM, rahul wrote:
>
>> So to summarize, this is our plan for Rubocop:
>>
>> - We propose to enable AndOr cop in small chunks, giving preference to
>> those files/directories that are heavily in development.
>> - Fo
On Tue, Aug 5, 2014 at 3:50 PM, rahul wrote:
> So to summarize, this is our plan for Rubocop:
>
> - We propose to enable AndOr cop in small chunks, giving preference to
> those files/directories that are heavily in development.
> - For AndOr, the conclusion seems to be to avoid keywords completel
So to summarize, this is our plan for Rubocop:
- We propose to enable AndOr cop in small chunks, giving preference to
those files/directories that are heavily in development.
- For AndOr, the conclusion seems to be to avoid keywords completely, and
ensure that the instances where they are used a
On Tue, Jul 29, 2014 at 4:42 PM, Andy Parker wrote:
> Right now the PRs are doing a mechanical transformation to remove a
> keyword that we don't want to use. What is missing is that it isn't
> transforming the code into what later changes to that code should preserve.
> Or put another way, if we
On Tue, Jul 29, 2014 at 4:53 PM, Jeff McCune wrote:
> On Tue, Jul 29, 2014 at 4:42 PM, Andy Parker wrote:
>
>> Here is an example
>> https://github.com/puppetlabs/puppet/pull/2900/files#diff-f9ef6a029a765863382f55a75a8fbd7cR27
>>
>
> Could you help me understand what it should look like?
>
>
if
On Tue, Jul 29, 2014 at 4:42 PM, Andy Parker wrote:
> Here is an example
> https://github.com/puppetlabs/puppet/pull/2900/files#diff-f9ef6a029a765863382f55a75a8fbd7cR27
>
Could you help me understand what it should look like?
-Jeff
--
You received this message because you are subscribed to th
On Tue, Jul 29, 2014 at 4:17 PM, Rahul Gopinath
wrote:
> Andy,
>
> [...]
> > Absolutely. I haven't looked at the full context of that statement, but
> > there is likely something that is being guarded by the return value of
> > execute_prerun_command, but the guard isn't made clear by the structu
Andy,
[...]
> Absolutely. I haven't looked at the full context of that statement, but
> there is likely something that is being guarded by the return value of
> execute_prerun_command, but the guard isn't made clear by the structure of
> the code. What the transformation does is to open it up to p
On Tue, Jul 29, 2014 at 1:35 PM, Adrien Thebo wrote:
> When reviewing pull request 2900 to add Rubocop and remove instances
> And/Or, I came across some rather interesting behavior with how the boolean
> operators interact with some keywords and methods. For the sake of clarity
> I'm copying my c
When reviewing pull request 2900 to add Rubocop and remove instances
And/Or, I came across some rather interesting behavior with how the boolean
operators interact with some keywords and methods. For the sake of clarity
I'm copying my comment from the pull request to here for discussion:
I'm conce
On Thu, Jul 17, 2014 at 10:06 AM, Rahul Gopinath
wrote:
> For the ease of management, I would like to split that into two PR,
> one dealing with the original Lint/* and a second one dealing with
> Style/AndOr since the number of violations of Style/AndOr is really
> large, and it may be better to
For the ease of management, I would like to split that into two PR,
one dealing with the original Lint/* and a second one dealing with
Style/AndOr since the number of violations of Style/AndOr is really
large, and it may be better to tackle it separately.
On Thu, Jul 17, 2014 at 9:23 AM, Adrien Th
I agree, I think it's better to get this system turned on and catching
issues now and we can add more cops later as the code base improves.
On Thu, Jul 17, 2014 at 7:11 AM, Kylo Ginsberg wrote:
> On Wed, Jul 16, 2014 at 10:34 AM, Rahul Gopinath
> wrote:
>
>> Thanks, I have updated the PR
>>
>>
On Wed, Jul 16, 2014 at 10:34 AM, Rahul Gopinath
wrote:
> Thanks, I have updated the PR
>
> https://github.com/vrthra/puppet/commit/f4f9fc4e333b2e53d63ca4b8e00d02a4f2bd47f8
>
> On Wed, Jul 16, 2014 at 10:03 AM, Erik Dalén
> wrote:
> > right, the generated files are:
> > lib/puppet/parser/parser.
Thanks, I have updated the PR
https://github.com/vrthra/puppet/commit/f4f9fc4e333b2e53d63ca4b8e00d02a4f2bd47f8
On Wed, Jul 16, 2014 at 10:03 AM, Erik Dalén
wrote:
> right, the generated files are:
> lib/puppet/parser/parser.rb
> lib/puppet/pops/parser/eparser.rb
> lib/puppet/external/nagios/parse
right, the generated files are:
lib/puppet/parser/parser.rb
lib/puppet/pops/parser/eparser.rb
lib/puppet/external/nagios/parser.rb
They are generated from those .ry and .ra files.
On 16 July 2014 18:12, Rahul Gopinath wrote:
> I see only *.ra|*.ry files (no grammar.rb)
>
> | find . | grep gra
I see only *.ra|*.ry files (no grammar.rb)
| find . | grep grammar
./lib/puppet/external/nagios/grammar.ry
./lib/puppet/parser/grammar.ra
./lib/puppet/pops/parser/egrammar.ra
We are currently limiting the scanning to *.rb files
On Wed, Jul 16, 2014 at 12:21 AM, Erik Dalén
wrote:
> Don't know ho
Don't know how many they are causing, but you should probably exclude the
generated grammar.rb and egrammar.rb files. The PR should be updated to do
this as well.
On 15 July 2014 19:46, rahul wrote:
> The total number of offenses on enabling all cops is 38303, of which 8769
> are in lib/puppet/
On Tue, Jul 15, 2014 at 11:01 AM, rahul wrote:
> [..snip..]
>
>
>> and then there's been some discussion on the PR around these two cops:
>>>
>>> Style/AndOr
>>> Lint/AssignmentInCondition
>>>
>>> Each of those two checks catch coding patterns which both are a source
>>> of some bugs and, at the
[..snip..]
> and then there's been some discussion on the PR around these two cops:
>>
>> Style/AndOr
>> Lint/AssignmentInCondition
>>
>> Each of those two checks catch coding patterns which both are a source of
>> some bugs and, at the same time are idiomatic in certain cases. So there's
>> r
The total number of offenses on enabling all cops is 38303, of which 8769
are in lib/puppet/pops
Not all the cops may be useful, and a few of them are controversial.
On Monday, July 14, 2014 11:56:16 AM UTC-7, Brian LaMetterey wrote:
>
> Keep in mind that we can always take a layered approach. C
>
> Yep, I noticed that. Does houndci just work from the rubocop configs? If
>> it does, then I'd be a little worried that we are limiting ourselves to
>> only using rubocop for checking PRs. My concern might not be valid and it
>> is all going to be ok :)
>>
>
It does look like houndci is hardcode
On Mon, Jul 14, 2014 at 3:08 PM, Kylo Ginsberg wrote:
> So now putting on my opinionated hat ;)
>
> On Mon, Jul 14, 2014 at 12:04 PM, Andy Parker wrote:
>
>> On Mon, Jul 14, 2014 at 10:56 AM, Kylo Ginsberg
>> wrote:
>>
>>> For the build and test pipeline integration, I think it would be great
>
So now putting on my opinionated hat ;)
On Mon, Jul 14, 2014 at 12:04 PM, Andy Parker wrote:
> On Mon, Jul 14, 2014 at 10:56 AM, Kylo Ginsberg
> wrote:
>
>> For the build and test pipeline integration, I think it would be great to
>> have it as part of the PR process. However, since every once
On Mon, Jul 14, 2014 at 11:55 AM, Brian LaMetterey <
brian.lamette...@puppetlabs.com> wrote:
> Keep in mind that we can always take a layered approach. Could hire a
> small number of cops, then add more as our crime rate decreases.
>
Absolutely. This will be a living tool which we can tweak goin
On Mon, Jul 14, 2014 at 10:56 AM, Kylo Ginsberg wrote:
> HI all,
>
> We'd like to start using static analysis against the puppet code base both
> to catch certain classes of coding errors and to enforce best coding
> practices. Those are laudable goals of course, but there is plenty of room
> for
Keep in mind that we can always take a layered approach. Could hire a
small number of cops, then add more as our crime rate decreases.
Have we done an initial run to see how much crime we have? Is it a
daunting amount?
On Mon, Jul 14, 2014 at 11:07 AM, Rob Reynolds wrote:
>
>
> On Mon, Jul 1
On Mon, Jul 14, 2014 at 12:56 PM, Kylo Ginsberg wrote:
> HI all,
>
> We'd like to start using static analysis against the puppet code base both
> to catch certain classes of coding errors and to enforce best coding
> practices. Those are laudable goals of course, but there is plenty of room
> for
HI all,
We'd like to start using static analysis against the puppet code base both
to catch certain classes of coding errors and to enforce best coding
practices. Those are laudable goals of course, but there is plenty of room
for opinions on what qualifies. This email is a request to solicit some
37 matches
Mail list logo
