Ah ha! I knew that this was going to come up, and I'm somewhat prepared.

Both of your suggestions do have precedent in other Jakarta projects. I am open to the idea of having a coding standard specific to HttpClient. It is our right to have our own coding standard, if we so choose. Perhaps after some research, and discussion, we could propose a vote on a number of vaiations to the coding guidelines. The only restriction that I would put is that every particular style variation proposed as a concrete change to the checkstyle.properties file that is now in our repository.

I also expect some input from the commons proper guys.

Some other resources to consider:

http://jakarta.apache.org/site/faqs.html
http://jakarta.apache.org/commons/patches.html
http://jakarta.apache.org/cactus/coding_conventions.html
http://jakarta.apache.org/avalon/code-standards.html
http://jakarta.apache.org/velocity/code-standards.html
http://jakarta.apache.org/jetspeed/site/code-standards.html
http://jakarta.apache.org/commons/sandbox/net/code-standards.html
http://jakarta.apache.org/commons/latka/developers-guide.html

So talk about your suggestions, and post some precise proposals and I'll get them all togehter at the end of the week and we'll have a vote. (we should hold off on any style specific patches untill this is sorted out)

-jsd


Mike Bowler wrote:

I am going through the code and changing it to conform to the style as per checkstyle. There are two places that I think we may want to be a little more lenient than the defaults and so I'm putting them here for discussion.

1) Line length of 80

The number 80 originally came from the days when printers could only print 80 columns. These days, that number doesn't make nearly as much sense. While I think we still want to have a maximum length, I believe that 80 is too short.

In most of the places that we are exceeding the limit, we are just over by a bit (between 80 and 90). I propose that we change the max length to 100. This is still short enough that nobody should have to scroll to see the source but long enough that we aren't artificially breaking lines.

2) Instance variable names

Some of the code uses leading underscores for variable names but this isn't allowed by checkstyle. The pattern it checks for is ^[a-z][a-zA-Z0-9]*$

I find significant benefit to being able to quickly distinguish instance variables from local variables and the leading underscore lets me do that easily. (I personally prefer trailing underscores to leading ones but I can live with either)

I propose that we change the pattern for instance variables to ^_?[a-z][a-zA-Z0-9]*$ so that we will allow leading underscores but will not insist on it.

Comments?


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to