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
