The O class prefix is useful in the sense that it distinguishes for the end user. Though for the devs I suspect it confuses things somewhat. I'm a great fan of the convention of 'I' prefix for interfaces and no prefix for implementations. Though to alter that would mean altering the entire API. I wonder if a different prefix for implementation classes would be worthwhile? Given that most of the API is exposed via interfaces it would make sense to maintain O as an API prefix.
On 25/05/14 21:30, Luca Garulli wrote: > 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] > <mailto:[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] > <mailto:orient-database%[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] > <mailto:[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.
