On Saturday, 19 January 2013 at 17:25:58 UTC, Stewart Gordon
wrote:
On 18/01/2013 23:17, Era Scarecrow wrote:
Maybe, but if you use a newline instead of a semi-colon, then
you can't put multiple statements on the same line;
A newline as an alternative to a semicolon then.
newlines and spaces are more formatting so they were likely
rejected as part of the separator;
Not sure what you mean by that....
If newline was the separator then...
if (a == 1 && b == 2 && c == 3 && d == 4 && e == 5 && f == 6 &&
g == 7 && h == 8 && i == 9) //explanation of descriptions not
possible, likely before 'if' statement instead
{}
vs
// would break, no statement following &&;
// no matching )
if (a == 1 && b == 2 && c == 3 && //explanation of
conditions
d == 4 && e == 5 && f == 6 && //
g == 7 && h == 8 && i == 9) {}
Just cause it can be ugly doesn't mean there was times you could
avoid it. More modern compilers could optimize other statements
thereby simplifying it to..
bool t1 = a == 1 && b == 2 && c == 3;
bool t2 = d == 4 && e == 5 && f == 6;
bool t3 = g == 7 && h == 8 && i == 9;
//equal to above, assuming an optimizer would condense it
if (t1 && t2 && t3) {}
Course if you gave them names and something useful then you
might have something like:
if (memBlock && startSector >= 0 && endSector <=
memBlock->length && startSector < endSector && outBlock &&
outBlock->length >= (endSector-startSector)) {
...
} else {
assert(false, "memory bounds of sector xxx failed");
}
You could turn that into: (but not if newlines were separators)
if (memBlock && outBlock &&
startSector >= 0 && endSector <= memBlock->length &&
startSector < endSector &&
outBlock && outBlock->length >= (endSector-startSector))
{}
else {
assert(false, "memory bounds of sector xxx failed");
}
You'd be required to do this, depending on what you need to
keep the code readable; Although this break-down would help you
to give more exact error messages.
assert(memBlock && outBlock);
assert(startSector >= 0);
assert(endSector <= memBlock.length);
assert(startSector < endSector);
assert(outBlock->length >= (endSector-startSector));
//success code from here on.
But most likely for operating system code you wouldn't assert
it, you'd return error code numbers; A lazy programmer trying to
just 'get it to work' wouldn't want to get into a whole lot of
intricate error messages/enums until going through the code a
second time after he has a basic working model, so it's either
success or failure, nothing more, nothing less.
Besides, 95% of the time error codes like errorno are completely
ignored; Checking for every type of error in every case would
make the functions so large bulky and annoying and hard to read
it's impractical. ie:
//write to FILE fp, 100 records of 1 byte each, from void*
header
recordsWrote = fwrite(fp, 100, 1, header);
//recordsWrote not 0?
//errorno checks:
//did write correctly?
//out of space?
//was file even open anymore?
//was output read-only?
//other errors? (I don't know how many there are, some OS's
could have more)
//can retry if there was an error?
recordsWrote = fwrite(fp, 100, 1, data);
//repeat error checks
//if failed, remove previous header information?
At best I check on if any records were written, and only go back
to check/work if I seem to be having issues regularly.
Then invent a line-splicing notation. It's what Visual Basic
has done.
Maybe. I think (but not sure) that back when space was a lot
more precious (and harddrives of 300Mb were 'large'; In 1992 I
had a 300Mb hard drive, on a 386 SX 33Mhz laptop); Every k
counts, and a compact compiler/sources (instruction set in the
x86) made sense. So tabs were likely used far more for main
indenting/spacing than regular spaces (8:1 ratio, auto aligning).
Besides, Visual Basic is younger than C and has more freedom
after it came out when the hardware was a certain level.
Basic/Qbasic sorta count, but that're not VB.
Now understand I'm not saying you're wrong. I'm saying it was
impractical for the time based on hardware limitations (and a
young technology).
