Hi,
On Wed, Mar 12, 2014 at 7:09 AM, Julian Reschke wrote:
> I like consisting coding style, but then, I also like to be able to violate
> a rule in some cases.
+1
> That being said: there are more things we should check, such as line ending
> (svn:eol-style), use of trailing whitespace, or non
On 2014-03-11 16:41, Felix Meschberger wrote:
+1
Coding style is part of the corporate identity of the code, in a sense.
Regards
Felix
...
I like consisting coding style, but then, I also like to be able to
violate a rule in some cases.
That being said: there are more things we should chec
+1
Coding style is part of the corporate identity of the code, in a sense.
Regards
Felix
Am 04.03.2014 um 09:49 schrieb Thomas Mueller :
> Hi,
>
Question: why don't we use the maven checkstyle plugin?
>>> for what? we are quite liberal in coding style and respect personal
>>> preferences.
Hi,
On Tue, Mar 4, 2014 at 10:47 AM, Davide Giannella
wrote:
> I'm saying that with the proper tool in place this would have not happened
> as the build would (potentially) break if the formatting is not good.
The trouble with such tooling is avoiding false positives. Where do
you draw the line
Hi Jukka,
On 04/03/2014 15:12, Jukka Zitting wrote:
> Hi,
>
> On Tue, Mar 4, 2014 at 8:11 AM, Davide Giannella
> wrote:
>> I raised the topic as the issue I'm working with (OAK-1263) is costing
>> me quite some time in fixing formatting.
> The formatting wasn't broken to begin with, it was your p
Hi,
On Tue, Mar 4, 2014 at 8:11 AM, Davide Giannella
wrote:
> I raised the topic as the issue I'm working with (OAK-1263) is costing
> me quite some time in fixing formatting.
The formatting wasn't broken to begin with, it was your patch that was
changing perfectly valid formatting.
The problem
On 04/03/2014 08:49, Thomas Mueller wrote:
> Sure, the exact formatting rules are a matter of personal taste. But why
> do companies such as Google *enforce* specific rules?
>
> http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
>
>
> Becase most of the time, developers *read* the
On 03/03/2014 17:20, Tobias Bocanegra wrote:
> Hi,
>
> On Mon, Mar 3, 2014 at 6:14 AM, Davide Giannella
> wrote:
>> I just spent some time in fixing formatting issues...
> what would that be?
Well, spaces, line wrapping, indentation, that changed on an existing
class and Eclipse that decided to a
On 03/03/2014 21:50, Jukka Zitting wrote:
> As a general rule, if you're changing existing code, stick with the
> existing formatting (i.e. no line in a path should be about
> formatting, unless the patch is explicitly about that).
>
> If introducing new code, we use the standard Java coding conven
Hi,
>>>Question: why don't we use the maven checkstyle plugin?
>> for what? we are quite liberal in coding style and respect personal
>> preferences. the only checkstyle rules that make sense are the ones
>> that find or prevent bugs (like avoiding .* imports).
Sure, the exact formatting rules ar
Hi,
On Mon, Mar 3, 2014 at 12:20 PM, Tobias Bocanegra wrote:
> On Mon, Mar 3, 2014 at 6:14 AM, Davide Giannella
> wrote:
>> Question: why don't we use the maven checkstyle plugin?
> for what? we are quite liberal in coding style and respect personal
> preferences. the only checkstyle rules that
Hi,
On Mon, Mar 3, 2014 at 6:14 AM, Davide Giannella
wrote:
> I just spent some time in fixing formatting issues...
what would that be?
> ...for a pull request ;)
we don't use git directly but svn - so I don't really know why a pull
request would matter...
> Question: why don't we use the maven
Hello team,
I just spent some time in fixing formatting issues for a pull request ;)
Question: why don't we use the maven checkstyle plugin? In this way it
can check the styles (we could plug it in the pedantic profile) and it
could even fail the build if some exceptions occurred.
As an addition
13 matches
Mail list logo
