I agree with the suggestion to follow the MS Coding standard. It's a good general guideline. Specifically, I'd like to follow all guidelines put forth in the book:
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by Krzysztof Cwalina and Brad Abrams http://amzn.com/0321246756 There's also a lecture that Krysztof gave that's available as a offline video download here (the streaming version isn't available at the moment for some reason): http://download.microsoft.com/download/8/0/8/808412ec-2561-413d-a9e3-5cd47d37d763/FDGNetCast.zip With regards to the specifics of the API, I think we should try to bring together the existing forks (Lucere, Lucille, and Aimee.Net) and attempt to merge them into a single consistent alternative API for Lucene.Net. They all use similar but slightly different tactics to ".NETify" the codebase. Also, significant community feedback will be necessary before we proceed to far down that road. We'll have a lot of work ahead of us just getting up to date releases finished for the 1:1 API port. It's my opinion though, that these can be separate and parallel development efforts. I made a request of the community in the Lucere project mailing list to respond with ideas about what an ideal .NET API would look like, and how it would function. Specifically, I was hoping to get pseudo-code examples of how end users would like to use Lucene. Even something as simple as: using(var luceneIndex = new LuceneIndex.Open("C:\foo\bar")) { var hitDocs = from doc in luceneIndex where doc.Field["content"].Match("foo") select doc; } This represents a lot of ideas all in one little code snippet. Maybe this isn't an ideal API, maybe it is... If we collect a bunch of code samples from people like this, we can discuss the merits of various ideas for the API and settle on an ideal way to present the functionality of the library in a way that will integrate well with the .NET 3.5/4.0 environment. I didn't get a lot of responses in the Lucere mailing list but perhaps the Lucene.Net community will have some ideas. We should probably cross-post to the lucene-net-user mailing list with a request for ideas. Thanks, Troy On Fri, Dec 31, 2010 at 1:35 PM, Michael Herndon <mhern...@o19s.com> wrote: > *Net Idiomatic Api Version* > *We should probably be looking for with this criteria is readability & > getting people familiar with any new code base faster within their own > Idiom. * > * > * > Starting with a proposal that we use the internal Ms coding > guidelines<http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx> > for > the idiomatic version, not to make anyone's life miserable or coding less > enjoyable or anything. > > But its already documented, we can easily point to it without having to > write up our own guidelines, and everyone who works inside of .net should be > remotely familiar with it, meaning someone can just come in and crank out > code. > > If need be, we let people work on the code base in their own style and when > they are done working on a particular area, let them reformat it or just run > a tool that auto formats code before each release. > > I know their is religious wars fought over this stuff, I don't want to > create one. I could be wrong about the above, but what again, the goals > should be familiarity, comfort, creating a bigger community. > > Also uses of core Interfaces, Annotations, & Classes where possible. (What > are some of these that you would like to see other than IDisposable?) > > A good book to comb over with the latest edition is the "Framework Design > Guidelines" 2nd edition. > > * > * > > > -- > Michael Herndon >
