You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Fredrik Westermarck <fr...@mdh.se> on 2003/09/04 19:04:02 UTC

[lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

Henri Yandell wrote:

>>Hopefully I managed to get the diff right. I had to remove several lines
>>by hand because of differences in the indentation (space vs tabs?). Is
>>there any document that describes what codestyle commons-lang is
>>supposed to use?
> 
> In the long term, a maven site and checkstyle might enforce this, but in
> real terms the codestyle to use is the same as the nearest neighbour.

Since I haven't used maven yet, will it still be possible to build with 
ant only?

> So if you're adding a method to NumberUtils, follow the style of
> NumberUtils. If you're adding a new class to lang.time, follow the style
> of a core class in lang.time. If you're adding a new package, you should
> have a good general feel for the style already :)
 >
 > Basic rules of working on a community codebase I guess.

I used the same codestyle this time as for my previous patch to 
NumberUtils. When creating the diff for my previous patch I didn't have 
any problem with the indentation so I guess that the codestyle for the 
class changed when Phil commited it... :)

> There are some basic concepts in the DESIGN-GUIDE file which state how
> XxxUtils classes should be, and there is a checkstyle.xml in there, if you
> know how to read that.

No, I don't know how checkstyle.xml works, but it never too late to 
learn... I'll have a look at them and try to create a codestyle for my IDE.



Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

Posted by Fredrik Westermarck <fr...@mdh.se>.
Phil Steitz wrote:
>>> Strangely, the checkstyle plugin is not complaining about any tabs in 
>>> the code.  Are you finding these in the tests or in the /java sources?
>> The differences is mainly in lines that are blank.
>> In the cvs these lines contains 6 whitespace chars and there are no 
>> whitespaces in my local files. These differences are present both in 
>> NumberUtils and in NumberUtilsTest.
> Did you update after the first commit?  I did remove one blank line and 
> added braces around an if() construct before committing the first patch. 
>  I noticed that the missing braces were present in the second patch.

Yes, I did make an cvs update after the first commit.



Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

Posted by Phil Steitz <ph...@steitz.com>.
Fredrik Westermarck wrote:
> Phil Steitz wrote:
> 
>> Strangely, the checkstyle plugin is not complaining about any tabs in 
>> the code.  Are you finding these in the tests or in the /java sources?
> 
> 
> The differences is mainly in lines that are blank.
> 
> In the cvs these lines contains 6 whitespace chars and there are no 
> whitespaces in my local files. These differences are present both in 
> NumberUtils and in NumberUtilsTest.
> 
> 
Did you update after the first commit?  I did remove one blank line and 
added braces around an if() construct before committing the first patch. 
  I noticed that the missing braces were present in the second patch.

Phil

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




Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

Posted by Fredrik Westermarck <fr...@mdh.se>.
Phil Steitz wrote:

> Strangely, the 
> checkstyle plugin is not complaining about any tabs in the code.  Are 
> you finding these in the tests or in the /java sources?

The differences is mainly in lines that are blank.

In the cvs these lines contains 6 whitespace chars and there are no 
whitespaces in my local files. These differences are present both in 
NumberUtils and in NumberUtilsTest.



Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

Posted by Phil Steitz <ph...@steitz.com>.
Fredrik Westermarck wrote:
> Henri Yandell wrote:
> 
>>> Hopefully I managed to get the diff right. I had to remove several lines
>>> by hand because of differences in the indentation (space vs tabs?). Is
>>> there any document that describes what codestyle commons-lang is
>>> supposed to use?
>>
>>
>> In the long term, a maven site and checkstyle might enforce this, but in
>> real terms the codestyle to use is the same as the nearest neighbour.
> 
> 
> Since I haven't used maven yet, will it still be possible to build with 
> ant only?

The ant build still works fine.

> 
>> So if you're adding a method to NumberUtils, follow the style of
>> NumberUtils. If you're adding a new class to lang.time, follow the style
>> of a core class in lang.time. If you're adding a new package, you should
>> have a good general feel for the style already :)
> 
>  >
>  > Basic rules of working on a community codebase I guess.
> 
> I used the same codestyle this time as for my previous patch to 
> NumberUtils. When creating the diff for my previous patch I didn't have 
> any problem with the indentation so I guess that the codestyle for the 
> class changed when Phil commited it... :)

If it did, that was certainly not intentional.  Strangely, the 
checkstyle plugin is not complaining about any tabs in the code.  Are 
you finding these in the tests or in the /java sources?

> 
>> There are some basic concepts in the DESIGN-GUIDE file which state how
>> XxxUtils classes should be, and there is a checkstyle.xml in there, if 
>> you
>> know how to read that.
> 
> 
> No, I don't know how checkstyle.xml works, but it never too late to 
> learn... I'll have a look at them and try to create a codestyle for my IDE.

Just check out the docs here: http://checkstyle.sourceforge.net/

Phil

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