For years the official maximum line length in the FreeRADIUS has been 80 columns. There was no real reason for this other than to satisfy our project leader's nostalga for VT100 displays. As modern displays and code editors can display very many more columns, he has agreed to allow the hard column wrap to be extended to 120. Please update your page guides appropriately. Deeply nested sets of logic are still considered harmful, and yes we (still, have, to, use, this, retarded, argument, alignment, scheme); egyption braces for if (conditions) { } one true brance for functions () { } switch (es) { case 'not indented': break; // always indented }; for (lo; oo; ps) { } while (loops) { } and all (arguments, must, have, a, space, or newline, after, the, comma or semicolon) if (braceless) alan_will_beat_you_with_sticks; else if ((assignment = nested) with clubs; -Arran
Arran Cudbard-Bell wrote:
For years the official maximum line length in the FreeRADIUS has been 80 columns. There was no real reason for this other than to satisfy our project leader's nostalga for VT100 displays.
Well... not *just* VT100.
Deeply nested sets of logic are still considered harmful, and yes
we (still, have, to, use, this, retarded, argument, alignment, scheme);
Yes.
egyption braces for
if (conditions) {
}
one true brance for
functions () {
}
Yes.
switch (es) {
No... the brace goes on the same line as the switch statement.
for (lo; oo; ps) {
Same here. I *loath* the fanatical whitespace model of: if (a) { stuff } else { other } Half of my screen is taken up by brackets. If you can't figure out what code belongs where from the indentation alone, you shouldn't be programming.
all (arguments, must, have, a, space, or newline, after, the, comma or semicolon)
Yes,becauseIhaterun-onsentences.They'retoodanghardtoread. (see?)
if (braceless) alan_will_beat_you_with_sticks; else if ((assignment = nested) with clubs;
Hmm.... clubs. Alan DeKok.
On 19 Mar 2013, at 10:01, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
Arran Cudbard-Bell wrote:
For years the official maximum line length in the FreeRADIUS has been 80 columns. There was no real reason for this other than to satisfy our project leader's nostalga for VT100 displays.
Well... not *just* VT100.
Deeply nested sets of logic are still considered harmful, and yes
we (still, have, to, use, this, retarded, argument, alignment, scheme);
Yes.
It's (really, really, really, retarded, and, brittle, because, when, you, do, search, and, replace, it, messses, up, the, alignment)
egyption braces for
if (conditions) {
}
one true brance for
functions () {
}
Yes.
switch (es) {
No... the brace goes on the same line as the switch statement.
Really? I think that's wrong, it munges the first case statement with the condition, makes it harder to read.
for (lo; oo; ps) {
Same here.
ok...
I *loath* the fanatical whitespace model of:
if (a) { stuff } else { other }
Half of my screen is taken up by brackets. If you can't figure out what code belongs where from the indentation alone, you shouldn't be programming.
Yeah Allman style looks dumb for conditions but aids readability in everything else...
all (arguments, must, have, a, space, or newline, after, the, comma or semicolon)
Yes,becauseIhaterun-onsentences.They'retoodanghardtoread.
(see?)
Wasn't a criticism.
if (braceless) alan_will_beat_you_with_sticks; else if ((assignment = nested) with clubs;
On Tue, Mar 19, 2013 at 10:01:09AM -0400, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
For years the official maximum line length in the FreeRADIUS has been 80 columns. There was no real reason for this other than to satisfy our project leader's nostalga for VT100 displays.
Well... not *just* VT100.
This is nearly moving forward to a VT220 with a 132 column display... ...which is so hard to read you just set it back to 80 as soon as possible. (Yeah, they're still useful for managing switches.) I always try and code to 80 chars wide. Looking at code in a default xterm is really annoying when it goes over 80 chars, and it's hard to follow the code to the next line. But it's your decision. My xterm will stretch.
switch (es) {
No... the brace goes on the same line as the switch statement.
Yuck - agreed. Function declarations on the next line, everything else at the end of the same.
Half of my screen is taken up by brackets. If you can't figure out what code belongs where from the indentation alone, you shouldn't be programming.
...and why unlang isn't a programming language, as you can't do } else { :-)
if (braceless) alan_will_beat_you_with_sticks; else if ((assignment = nested) with clubs;
Hmm.... clubs.
There's a spare bracket in that statement that could be used to store the clubs, if required. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 19 Mar 2013, at 10:51, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Tue, Mar 19, 2013 at 10:01:09AM -0400, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
For years the official maximum line length in the FreeRADIUS has been 80 columns. There was no real reason for this other than to satisfy our project leader's nostalga for VT100 displays.
Well... not *just* VT100.
This is nearly moving forward to a VT220 with a 132 column display...
...which is so hard to read you just set it back to 80 as soon as possible. (Yeah, they're still useful for managing switches.)
I always try and code to 80 chars wide. Looking at code in a default xterm is really annoying when it goes over 80 chars, and it's hard to follow the code to the next line. But it's your decision. My xterm will stretch.
It was getting annoying. There are some situations where you can't avoid the levels of nesting, "and doing hard " " truncation of log " "messages is an " "absolute PITA."
switch (es) {
No... the brace goes on the same line as the switch statement.
Yuck - agreed. Function declarations on the next line, everything else at the end of the same.
Fine... switch (foo) { case bar: break } looks squished to me. But whatever.
Half of my screen is taken up by brackets. If you can't figure out what code belongs where from the indentation alone, you shouldn't be programming.
There's a spare bracket in that statement that could be used to store the clubs, if required.
It was omitted for just that reason.
On 19 Mar 2013, at 11:01, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 19 Mar 2013, at 10:51, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Tue, Mar 19, 2013 at 10:01:09AM -0400, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
For years the official maximum line length in the FreeRADIUS has been 80 columns. There was no real reason for this other than to satisfy our project leader's nostalga for VT100 displays.
Well... not *just* VT100.
This is nearly moving forward to a VT220 with a 132 column display...
...which is so hard to read you just set it back to 80 as soon as possible. (Yeah, they're still useful for managing switches.)
I always try and code to 80 chars wide. Looking at code in a default xterm is really annoying when it goes over 80 chars, and it's hard to follow the code to the next line. But it's your decision. My xterm will stretch.
It was getting annoying. There are some situations where you can't avoid the levels of nesting, "and doing hard " " truncation of log " "messages is an " "absolute PITA."
Make that wrapping. I'm sleepy. -Arran
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton