opennlp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aliaksandr Autayeu <aliaksa...@autayeu.com>
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
look?


> 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.
>
OK.


> 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?
> http://uima.apache.org/**codeConventions.html<http://uima.apache.org/codeConventions.html>

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.

Aliaksandr

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