[jsword-devel] coding conventions

[Manfred Bergmann]

Now or whenever you are ready is fine for me.


Manfred

Am Donnerstag 29 Oktober 2009 13:14:12 schrieb 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
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>