> Anything that breaks a previously unbroken argument list will reduce the
> readability in my opinion. The lines can of course not be unlimited,
> but there is no need to set the limit as low as 80 columns. Feedback
> I've got from developers using e.g. 80 column braille devices is that
> longer lines isn't really a problem for them either.
The main reason for limiting the line length is so that things look
'sensible' when you have a lot of screen windows displaying different
files. You don't want wrapped code, and you definitely don't want
the RHS of long lines hidden.
With a 1600x1200 monitor I'll display six 80x40 windows (and probably
have some more partially visible ones).
Personally I indent continuation lines by 4 chars if using 8 char
'normal' indentation and 8 chars if using 4. This gives a lot more
room on the continuation lines than the Linux 'line up with the
previous line'.
> This is the only one of your code changes which I can be convinced to
> agreeing may improve readability:
>
> - if ((on && || (!on && atomic_dec_and_test(&info->pmcount))) {
> + if ((on && atomic_add_return(1, &info->pmcount) == 1) ||
> + (!on && atomic_dec_and_test(&info->pmcount))) {
That can be written succinctly as:
if (on ? atomic_add_return(1, &info->pmcount) == 1)
: atomic_dec_and_test(&info->pmcount)) {
although that construct is somewhat frowned upon!
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
