-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

<snip>
> My only remaining question then is should we also be forcing whitespace between each case block for legibility,
> something like this?
> 
> do_something(); switch(foo)  { case bar: a=1; break;
> 
> case baz: { a=2; ...long case block... c=4; break; }
> 
> case asd: a=3; break;
> 
> default: a=0; } do_something_else();
> 

Empty lines between cases makes reading a little easier IMO. Sounds like a good idea to me.

<snip>
>> if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype &
>> TDEDiskDeviceType::CDRW))
> 
>> or
> 
>> if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype &
>> TDEDiskDeviceType::CDRW))
> 
> I am curious as to why you find this more intuitive than having the logical operator before the comparison.
> Roughly translating to English the above style reads something like:
> 
> if the box is black AND <pause> the box is not square AND <pause> the sphere is purple OR the sphere is NOT PRESENT
> THEN
> 
> versus
> 
> if the box is black <pause> AND the box is not square <pause> AND the sphere is purple <pause> OR the sphere is NOT
> PRESENT <pause> THEN
> 
> You can see how in the latter style the relevant logical operator is stated first, then the expression, with all
> required information to understand the conditional contained on one line instead of spanning two lines.  The latter
> is easier for me to grasp all of the conditions required in a large expression; the former requires a bit more
> effort.
> 
> It isn't a big deal either way for me, and I'd like Slavek's input before deciding, but I am curious as to the
> thought processes behind the suggested style. :-)
> 
This is of course subjective and not a big deal for me as well (I have already worked with both style actually).
Mostly two reasons:
1) the operator at the end of the line tells me immediately that the conditional expression is not over and I need to
continue reading the next line
2) logically easier to read complex statement. For example

if (a == 3 &&
    (b == 5 || c == 4 ||
    (d == 10 && e == 20)))

rather than:

if (a == 3
    && (b == 5 || c == 4
    || (d == 10 && e == 20)))

I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the
&& in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-)
Just my 2 cents, let's see what Slavek thinks as well.

Another thing is class/struct member names. I usually add an "m_" to every member, so I know immediately that a
variable is a class member. TDE is a very wide variety of class member names. What is your opinion?

Another thing is class constructor parameter definition. Which one is better?

MyClass::MyClass(int i, char c, int *p, double d) : m_i(i), m_c(c), m_p(p),
    m_d(d)
{
  do_something();
}

or

MyClass::MyClass(int i, char c, int *p) :
  m_i(i), m_c(c), m_p(p),
  m_d(d)
{
  do_something();
}

or

MyClass::MyClass(int i, char c, int *p)
  : m_i(i), m_c(c), m_p(p),
    m_d(d)
{
  do_something();
}

or

MyClass::MyClass(int i, char c, int *p)
  : m_i(i),
    m_c(c),
    m_p(p),
    m_d(d)
{
  do_something();
}

or

MyClass::MyClass(int i, char c, int *p) :
  m_i(i),
  m_c(c),
  m_p(p),
  m_d(d)
{
  do_something();
}

Cheers
  Michele
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJUsKmoAAoJECp1t8qK3tXPULIP/1+e3LQ/4OGFymV9XrBHY9lT
yfuqXHXtPRucPQTsJLQ5sei1VxGlXPcoMqrRAFD/mMGGPsfqi/8Uj2VreOo8w3yB
sFjod/NtvvU5vk4uJQnbZn6O6FJn3Dr51KeCu+1dB/jhWCquD53oZCuDHh4asbRG
LsDRoleq8HHh241ciaLr/MdPd2VVau8jztEmO/OkuLAlcut9ebxtNNB37v3YOS5T
OvEdHqLDUb7vkIxaDjsuOviE+mbgfWtYKaxBTNwm31uiHDxfsEJNMpPt/UIahrNk
2H3RIrLbncnxBMblL4faYjbXHV09/QBiKuLCEYeXi1+1VUuZBU1H6Ce9D/UJoIrA
Qvsq4kgmzayLQ/0iUVo8KmtjGodXz5uxXUTRjFJkY9C7YOjbFJSZEZBGHB4rD0YK
/zO5DJCcdLMBGYkBkK2sdrA+ujwDEOaNXmvFiDel3XJUvfgkXOIsKhd4HHN8IzrJ
3bpYLb+osjfezvSC923VBwHLjxG4h14FC9WW45wzoyJ8dEtDn6690LQnjj7R1t7X
VqHilFMXUCDsNYP4eCr9VzkQOE0PLj73UfqaaVhJJVYi2OEfae5rIjkCDPV7hbUP
9y02l32AsW6EuCUQOs1SPdeI+xlXyuAp1OJmQ3wcndIE7yOjRolaIm83MpjdOkCl
9zjTw818YSPDc5aDhIyO
=QWhp
-----END PGP SIGNATURE-----