Hey, There's a few more obvious things missing, I think - e.g. should new code use lower_case_with_underscores naming style or mixedCase ?

On Sun, 2008-01-13 at 17:39 +0000, Daniel P. Berrange wrote: > 2. Do not use conditionals in front of 'free'. > > eg Instead of > > if (foo) free(foo) > > Use > > free(foo) That's only safe with glibc, right ?

On Mon, 2008-01-14 at 14:11 +0000, Daniel P. Berrange wrote: > On Mon, Jan 14, 2008 at 08:40:35AM +0000, Mark McLoughlin wrote: > > Hey, > > There's a few more obvious things missing, I think - e.g. should new > > code use lower_case_with_underscores naming style or mixedCase ? > > Really ? About 70% of our code currently uses mixed case, no underscores. > The QEMU/network driver file & mdns file are the main ones which don't. But does the 70/30 split imply that it's okay for people writing new code for libvirt to use lower_case_with_underscores or not? I'm guessing not, especially since all your storage stuff is mixedCase, but it'd be worth pointing out in HACKING.

My main point was that some details on what is considered to be the libvirt coding style (aside form indentation) might help people.

There's a few coding style guidelines we've kind of informally agreed upon wrt to libvirt patches, and perhaps more that we ought to make decisions on. For the benefit of people sending patches I reckon its worth writing these down. So I'm attaching a proposed doc 'HACKING' in which we can detail the guidelines. And yes, we don't uniformly comply with these guidelines in all places....all the more reason to list them & fix cases where we don't comply :-)

"Richard W.M. Jones" <rjones(a)redhat.com&gt; wrote: > Daniel P. Berrange wrote: >> There's a few coding style guidelines we've kind of informally agreed upon >> wrt to libvirt patches, and perhaps more that we ought to make decisions on. >> For the benefit of people sending patches I reckon its worth writing these >> down. So I'm attaching a proposed doc 'HACKING' in which we can detail the >> guidelines. And yes, we don't uniformly comply with these guidelines in >> all places....all the more reason to list them & fix cases where we don't >> comply :-) > > 5. Ensure any user visible strings are marked for translation > > eg wrap all strings with _(...) > > virXendError(xend, VIR_ERR_INTERNAL_ERROR, > _("domain information incomplete, missing domid")); > > Translating error messages is a bad idea: (1) Naive users ignore error > messages anyway. (2) It makes the error message much less useful when > doing an internet search for solutions. (3) If an error message is > posted to this list, it's much less useful if it isn't in English. Hi Rich, I've always heard that support for translatable diagnostics is an important feature. While I'm no UI/internationalization expert, I would have thought that less-savvy users would need the messages more than others. If a user is taking the time to report a bug to an English-speaking list and to include a precise diagnostic, they're probably clueful enough to translate any such message for us. At worst, since we have the .po files, we can look up the translation manually -- or just use an online translator.