There are things best done with regular expressions, just not as many as they get used for.
It *might* make the code more readable, especially if that is an established house style. The general point holds though - source code is for people to read and should be clear to them.
Didn't find your answer? Ask the community — no account required.
T
Tony van der Hoff
Yes; that's the way to do it!
A
Ahem A Rivet's Shot
If you had to work on a single 24 line, 80 column screen you would want to conserve lines too - those three lines saved are an eighth of the available screen space.
Like the often criticised use of null terminated strings the choice made sense in context.
I do too - but less indented than you - so they align with the enclosing block rather than the enclosed.
A
Ahem A Rivet's Shot
a nice example of how *not* to use ternary expressions, not as bad as recursing in multiple ways in the expression though.
S
scott
This, except I'm likely to leave them out if they only enclose a single statement. I'd use this:
void function(int arg) { if (arg) do_this(); else do_something_else(); }
If a piece of code expands beyond one statement, then I'll add the brackets:
you were lucky, Most of us had a one line teleprinter
>
C
Charlie Gibbs
That depends on how you define "level". Syntactically, they _are_ on the same level; they're just in different columns. The above example keeps the line count down. I prefer concise code as long as readability isn't compromised, and I don't have trouble with the opening brace being off to the right. Neither does vi - put the cursor on one brace and hit "%", and it'll find the corresponding one wherever it is.
Agreed. I think of the braces as a container, so they belong on the outer level, as opposed to the contents of the container.
I do this except that I don't allow code to jump up more than one level at a time, as the last two lines of your examples do. I insist on seeing something at each level on the way out. This rule requires a closing brace after do_something_else().
The braces around do_something_else() are required by my rule. The ones around do_this() aren't strictly necessary, but since I've put braces around do_something_else() I put them in for consistency. (I'm a big fan of consistency.)
I don't mind a few extra characters if they reduce ambiguity. That's why I write things like:
if((x == 1) || (x == 3)) ...
A few extra parentheses are quicker to write (or read) than trying to remember subtleties of operator precedence.
A
Ahem A Rivet's Shot
I didn't mean me, I meant Kernighan, Ritchie, Pike et al - a hand card punch is the least convenient editing device I have used.
N
NY
What's that in English?
if (a==b) x = a++; else x = b++ + c++;
Or throw the coder away ;-)
The old "if (a==b)" reminds me of one of my last-minute checks I make of any code:
The two txt files should be the same, or there should be a small number of differences that can be reviewed on a case-by-case basis.
I'm looking for the dreaded "if (a=b)" test which is almost never what is intended ;-)
As regards
if (a ==b) { lines } else { lines }
versus
if (a ==b) { lines } else { lines }
I tend to prefer the first because I tend to think of the braces as belonging with the code they embrace, but I'd not make a hard and fast rule as long as it was done consistently.
I tend to use two spaces for each level of indentation because it's enough for the indentation to be easily visible by eye without the code disappearing off into "indentation hell" off the RHS of the screen/window with very few levels of nesting.
A
Adam Funk
Was this partly to make himself indispensable (i.e., no-one else would be able to patch his code)?
M
Martin Gregorie
The old 12 key punches were damn good for fixing single single character mistakes provided your computer used a optical card reader with a straight card path. Fortunately this was the case for all ICL 1900 card- readers. We used to do that all the time. Beat the crap out of repunching a whole card.
Not so good on an ICL 2900, however: they had a 4000 cpm optical card reader but the card path had a fairly large diameter semicircle in it where the card passed the optical sensors on its way to the output card stacker. That turn was tight enough to eject any manually implanted card chads from their holes.
And, of course no good at all if the card reader was old enough to use copper brush sensors.
M
Martin Gregorie
No, because he'd long gone before I had to make changes to code he'd previously amended. That programming shop has absolutely no discernable programming standards - every system thy had seemed to have invented its own and the analysts, who kept themselves very much to then selves in another part of the building never kept amendment documentation: as soon as the patched code went live, the fix documentation went in the bin.
Amazingly, the company still exists....
A
Ahem A Rivet's Shot
For tests like if (x==3) writing it as if (3=x) generates an error if you miss out the second = like I just did - one legal reversal of convention that is useful, unlike using 5[x] insteadof x[5] which just confuses people.
A
Ahem A Rivet's Shot
We used a 1442, sort of like a baby MFCM. I got quite adept with the card saw.
D
druck
You could come up with a similar contrived example in just about any language.
---druck
D
druck
I saw a similar technique used to protect commercial software written in BBC BASIC from being plagiarised. As it was interpreted BASIC it had to be supplied in a form which could be read by both humans and the computer, but they had renamed every variable and every procedure to a variant of 'ClaresMicroSupplies' with each instance have a different combination of upper and lower case letters. The computer could still execute it, but humans just find it impossible to distinguish between the variants.
---druck
D
druck
Agreed!
Heresy! The one true form is:-
if (a==b) { do something } else { do something }
---druck
N
NY
I like it. Looks a bit odd but it's good defensive coding.
The writers of compilers actually allow 5[x] as a synonym for x[5] (where x is an array)? WTF!
A
Ahem A Rivet's Shot
j[i] = ++i[j++];
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.