There is no "private field" example, but a "protected field" example on page http://msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx and the variable name is in camelCase.Anyway, here's what been used in DbLinq: - private fields are like "_privateField" (underscore + camelCase) - internal methods are, for now, like "_InternalMethod" (underscore + PascalCase) So I suggest we stick with this (I don't like underscores neither, but we can not break everything ;))
Regarding the databases, getting all of them in a VM has an advantage: every contributor can download the VM and use it locally, which is much more convenient for development. On Thu, Oct 16, 2008 at 21:09, Stefan <[EMAIL PROTECTED]>wrote: > > Hi, > > in the naming guideline there is nothing specific about how to name > private member variables. > My experience just tells me to use some way to mark somthing as an > class variable (because otherwise it is really hard sometimes when > reading code to determine the scope of variables), if it is an > _Member, mMember or Member_. > > > About the integration server, it would be enough if there are people > with this databases installed on web reachable boxes and create a > database for unit tests, then there is no need to have every database > on one server. > > On Oct 16, 8:37 pm, "Pascal Craponne" <[EMAIL PROTECTED]> wrote: > > Stefan, > > nice to read this message, you seem to have good practices. > > My answers: > > - "protected virtual", no, there is no sense, usually it means that I > wrote > > the class, since I'm the only one doing this. It comes from my experience > in > > refactoring, but it is useless most of the time :) Do what you want for > > this. > > - naming conventions, we use .NET naming conventions, as described > athttp://linq.to/db/DevelopmentGuidelinesand it doesn't include the "m" > > prefix, so we don't use it. Also, I don't like prefixes, it reminds me > the > > old times of MFC (and the hungarian notation, which still makes me hurl). > > - your conclusions regarding tables, ok, just don't forget to register > > associations too. > > - ok for database name > > - continuous integration would be great, but we require a server with all > > databases running before doing this. A long time ago I was thinking to > > distribute (and update) a Linux VM with these, but my linux (as my > english > > :)) sucks, so we're still looking for volunteers. > > > > You contribution is greatly appreciated, thanks. > > > > Pascal. > > > > -- > > Pascal. > > > > jabber/gtalk: [EMAIL PROTECTED] > > msn: [EMAIL PROTECTED] > > > -- Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
