Hi Steve, about formatting we all use the settings contained in: _base/ide/eclipse-formatter.xml
Works on both Eclipse and IntelliJ. About long methods... Well there are some parts pretty old in the code and/or need a refactoring. Every tuesday we do a "docathon" where we al spend 1-2 hours to improve JavaDocs (at least the API classes) and the Wiki. The reason for the O as class prefix was my idea for the first prototype 5 years ago, then it's remained as "convention". the "i" as prefix of parameters tells are input parameters, but this is not a rule. Lvc@ On 25 May 2014 12:04, Steve <[email protected]> wrote: > Just wondering is there an official style guide for orientdb code? I've > come across a few different styles that look like conventions but they > are quite different from each other. The only one that is really > consistent is prefixing all classnames with 'O' and for a reason I can't > figure out, prefixing method params with 'i' e.g. iFieldName. > > I also notice in general the code is very compact. There's no blank > lines between logical blocks of code and lots of very looooong methods. > This tends to make it very hard to read. > > I'd really like to see an effort to address this as well as seriously > improve the javadoc. I'd also be willing to be part of that effort. As > I find myself regularly trawling through various parts of the code it > would be fairly trivial to add some javadoc whenever I read the code of > a method to work out what it does. Not to mention inline comments to > assist understanding the flow of methods. Or refactoring large method > chunks into methods of their own. > > Would the ODB team be willing to entertain embracing a code styling > convention? Personally I'm a fan of the result you get in eclipse with > Shift+Ctrl+F. It's neat easy and easy to read and so common that you > avoid the common DCVS issue where someone formatting code in a class > causes a massive diff in the next commit that obscures the real changes > in the code. > > You would probably start by just opening every single class one by one > and running a standard eclipse format command on it then making one huge > commit. This would contain the DCVS fallout to that single commit. It > would probably be ideal to do this just after a release when the develop > branch has been merged with HEAD. > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
