[jsword-devel] coding conventions

[DM Smith]

I've put together a patch for this. It is a big one. Manfred and any  
one else that has changes to the code, let me know when would be a  
good time to do this. I was thinking that I'd do it after I get back  
from work in 8-10 hrs from now. I can hold off on individual files,  
too. Just let me know.

The basics:
Sun Java coding standards with the following changes:
Don't reformat block comments /* ... */
Code lines can be 160 characters long.
No tabs in code.
Indentation is 4 chars.

In Him,
	DM

On Oct 28, 2009, at 6:32 PM, bergmannmd at web.de wrote:

> Am Dienstag 27 Oktober 2009 19:47:40 schrieb DM Smith:
>>
>> I'm up for a change on this one. We just need to settle on a good
>> convention. (Input wanted!)
>>
>> I've never been a fan of { being on it's own line, except when it
>> enhanced readability, as in:
>> if (a &&
>>      b) {
>>      c;
>> }
>> Where a && b is really any compound condition spanning several  
>> lines and
>> c appears to line up with the list of conditions. In this case I  
>> want to
>> have something to set c apart from the conditions.
>> This could either be the double indentation of the continuing  
>> conditions:
>> if (a &&
>>         b) {
>>     c;
>> }
>> Or of { being on the next line:
>> if (a &&
>>      b)
>> {
>>      c;
>> }
>
> I think I would find the second one the best.
> But if such a compound condition really is very long it should be  
> put into a
> method for better readability. So that you have:
> if(isConditionTrue()) {
>    c;
> }
>
> boolean isConditionTrue() {
>        return a && b;
> }
>
>> I think the extra indent makes a bit more sense and is easier to  
>> enforce
>> with checkstyle.
>>
>> Also, I think that for the sake of maintenance and adding new
>> expressions (e.g. debugging) that all single expressions are in a  
>> block.
>> That is, not:
>> if (condition)
>>    expression;
>>
>> and that there are no one liners:
>> if (condition) { expression; }
>>
>> I also prefer:
>>     } else {
>> over:
>>     }
>>     else {
>
> I second all of the above.
>
>>
>> Regarding methods, it gets pretty long to have:
>> scope returnType methodName(parameterList) exceptionList {
>>     code;
>> }
>> I think this and class declarations are two places where { should  
>> be on
>> the next line. But I could be persuaded otherwise.
>
> In my opinion parameters lists shouldn't be that long.
> 3 Parameters to a method are many except it is some static stuff.
> With that lines are not very long and the { can be on the same line.
>
>>
>> If we change, I'd like to do it one package at a time and have
>> consistency within a package. The Eclipse formatter will make easy  
>> work
>> of it.
>
> Yeah, the IDE can reformat it on one pass.
>
>
>
> Manfred
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel