opennlp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aliaksandr Autayeu <>
Subject Re: eol and code style
Date Fri, 11 Nov 2011 15:10:24 GMT
Thank you for information! I still have questions, please, can you take a

> 1) What is the official line-ending style for project code source? That is,
>> win? unix?
> We are using subversions svn:eol-style native property, which will ensure
> that you always get the native styles when you check out. We just recently
> fixed that and set this property on all files in the opennlp folder,
> sandbox
OK, got this. However, this is SVN-specific :) And I'd like to know what is
inside the repo (crlf or lf) because I use git, because apache mentions,
but does not say anything specific about using git and eol apart from YMMV
:) and because my patches are a little too big. I'm just trying to find
right combination of settings.

2) Which eol settings are important in version control systems? That is,
>> convert\leave in SVN, Git, ...
> I believe Git doesn't get the eol-style property from subversion, I think
> on of the apache git pages mentioned that. Maybe that is why your patches
Yes, they do. But they do not give advice on which settings to use with
git. They say YMMV :)

> often remove/add entire files, even if only a couple of lines have been
> changed.

Exactly. I think this is not convenient.

>  3) Is code style (and formatting rules) documented somewhere? That is -
>> comments, bracing, line wrapping, line length... I have found that on some
>> points (for example I prefer forced braces on if and for statements,
>> because this helps avoiding certain bugs) there is divergence and least
>> I'd
>> like to do is to adopt project style.
> We don't yet have a code style guideline, people tend to disagree on
> smaller
> formatting things, e.g. place else on the same line or new line, if
> statement
> only with braces or for one-statement ifs only without, etc.
Oh yeah, they do, been there :)

> In my opinion that is not so important, but important is that people not
> always change everything to their personal flavor. They should write
I'm adopting existing code style and made some obvious tweaks already to my
IDE, like 2-space indents. Actually, so far the only opinion I have about
code formatting is about enforcing braces for if and for. The reason behind
is to avoid bugs on editing: if there are no braces, it is easy to forget
to add them when one adds another statement to if or for. Other rules are
more a matter of taste. Or at least I don't know reasons backing them up.
Anyway, I'm a newcomer here and I do not reformat existing code.

> new code in their style but converting existing code just makes things
> difficult
> to diff and code changes hard to review.
Exactly the reason I ask. I'm glad we share this point of view.

> What we usually do is that we use 2 spaces to indent, instead of tabs
> and the max line length is somewhere between 80 and 100. Maybe we
> should make it 100.

> You are welcome to help us writing down some rules, I believe it should be
> mostly sun guidelines with a very few exceptions.

> Maybe like the UIMA ones?

UIMAs one looks OK to me. A good thing they did is exporting Eclipse
config. This settles down minor details.

> I think that would be a good fit for our source code.
> You can also send us patches for the website, but that seems not be
> in git. Just had a quick look over at Github.

That's OK, I've cloned it using git-svn.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message