PROS/CONS: #define BEGIN {

[Chris Croughton]

EOL processing can be made fairly painless. An EOL (carriage return) is

EOL is not necessarily "carriage return" (I believe some Macs use it,
nothing I've ever used). EOL is anything the implementation wants
external to the C program (including no character at all if lines are
counted strings) and is represented by the character '\n', 'newline', in
C.

quite different from a mere space and it would be a shame for the compiler
to completely ignore this extra *information* in a source file.

Would it like to use the spaces for indentation as well? I know at least
one language which does -- and just like using EOL it's a pain more
often than it is useful.

For example EOL can be ignored when following a symbol that is *expected* to
be followed by something else, such as "+". And converted to ";" (or acts as
statement terminator) otherwise. Use "\" to override this behaviour in the
latter case and ";" in the former, if it should ever be necessary.

Awk and Python are in other newsgroups.

Some conventions need to be used, for example it is necessary, if splitting
'a+b', to write:

a+
b

rather than:

a
+ b

As it happens, that's how I usually break lines anyway by choice.
However, there are millions of lines of code which use the opposite
convention according to local coding standards (I've had to write many
thousands of them) which would be broken by such a change.

In practice multiple EOLs (blank lines) must be treated as one and the
compiler should be tolerant of consecutive ";"s. The biggest problem (I will
mention it before anyone else) is sending source code over networks that
wrap lines at arbitrary points.

Anything which wraps lines, like editors and "beautifiers", is likely to
break it.

A bigger problem is that it is not obvious visually without doing a
parse whether a statement is finished or not. In your second example it
is perfectly obvious visually that what is meant is a + b, but your
compilers will take it as two statements, a and +b (presumably without
giving a warning, since both would be valid statements).

If you want a different language, use it. Having a semicolon which
terminates statements (as opposed to separating them as in Pascal) is
something with which most C programmers have no problem.

Chris C

 

[Bart C]

.
If you want a different language, use it. Having a semicolon which
terminates statements (as opposed to separating them as in Pascal) is
something with which most C programmers have no problem.

For some appls I need a tight, compiled language like C. I want to use a
mainstream language so the choice is between C and ASM. I think writing C is
easier. The semicolon business is a bit of a pain but not a big deal.

It's just a shame that language syntax is bound so tightly to the rest of it
that no-one can see that there could be a choice without having to switch to
a totally different and inappropriate language.

Bart.

 

[Chris Croughton]

For some appls I need a tight, compiled language like C. I want to use a
mainstream language so the choice is between C and ASM. I think writing C is
easier. The semicolon business is a bit of a pain but not a big deal.

I think that writing C is easier than writing assembler as well. You
could use Fortran if you want it line oriented, that's tight enough for
heavy-duty number crunchers and is compiled (indeed, if you use GCC it
is compiled by exactly the same "back-end" so the code will be just as
'tight')...

It's just a shame that language syntax is bound so tightly to the rest of it
that no-one can see that there could be a choice without having to switch to
a totally different and inappropriate language.

You are free to write a preprocessor for your different language which
converts it to C, and to try to get it accepted. I suspect that when
you get to try to do it you'll find a number of ambiguities which don't
do what you think is 'natural' easily (having used Awk and looked at
Python and Javascript among others, I find that breaking lines where I
find it natural to do so causes more problems than are solved by the
absence of the semicolon).

How many computer languages do you know which have the flexible and
redefinable syntax you want? Basically, a computer language is defined
by its syntax (if C looked like Pascal or Fortran it wouldn't be C!).
The more flexibility the more difficult the maintenance, because the
next person looking at it will have to learn essentially a different
language (this happens with customised editors as well).

Chris C

 

[Thomas Stegen]

Pro - fewer nesting errors...

Well, how often do you have nesting errors? I can't remember when I
last saw or heard of one. And it is not obvious at all to me that
BEGIN and END are easier to remember to put in than { and }.

Especially if you are using a syntax aware editor then you will
immidiately see a nesting error.

Though one thing that does reduce nesting errors is to put in both
brackets (be the parens, curly or square) before the code that goes
inside them. Since I started doing this a good few years ago now
(relative to my relatively short experience of programming) nesting
errors have more or less disappeared.

 

[Thomas Stegen]

Or other ugly things, none of which beyond a 72 char wide text line
should be necessary.

I used to follow this. Though, when I stopped a month ago or so
I found that code became easier to write and to read.

Not by much though since lines of that length are quite rare anyway,
It is usually only the occasional if statement which goes further.

I just used judgement, if it makes something easier to read I'll do
it unless it breaks with in house coding style (which is quite lenient
without causing any problems).

 

[Richard Bos]

Well, how often do you have nesting errors? I can't remember when I
last saw or heard of one. And it is not obvious at all to me that
BEGIN and END are easier to remember to put in than { and }.

Point in case: I was hand-hacking a Windows resource file last week.
Windows resource files use BEGIN and END. I forgot nearly all the
second-level BEGINs, because to my mind, POPUP plus indentation already
defined the beginning of the block. Using C, I hardly have to think to
just put the { at the end of the if/while/for-line.
Ok, this may be influenced by me being more used to { } than to BEGIN
END, but it's enough to show that BEGIN and END aren't inherently less
nesting-error-prone.

Richard

 

[Chris Croughton]

I used to follow this. Though, when I stopped a month ago or so
I found that code became easier to write and to read.

I find 72 characters is too limiting, especially with 4 characters per
indent level (which was imposed on me at work, I was preferring 2
characters, and I then found that 4 makes it more readable).

Not by much though since lines of that length are quite rare anyway,
It is usually only the occasional if statement which goes further.

I find that function calls do it, if statements do it more.

I just used judgement, if it makes something easier to read I'll do
it unless it breaks with in house coding style (which is quite lenient
without causing any problems).

Exactly.

Chris C

 

[CBFalconer]

.... snip ...

I find 72 characters is too limiting, especially with 4 characters
per indent level (which was imposed on me at work, I was preferring
2 characters, and I then found that 4 makes it more readable).


I find that function calls do it, if statements do it more.

Such function calls usually should be broken into one line per
parameter anyhow, maybe per associated parameter pair in some
cases. I consider conditional statements that can't be similarly
broken to be much too complex anyhow.

 

[Goran Larsson]

I find 72 characters is too limiting, especially with 4 characters per
indent level

I indent using tabs set to 8 characters for readability *and* because
it reaches the right margin on a typical 80 character editor window
after a reasonable nesting depth.

If the text falls over the right margin then I take this as a sign that
the logic is too complext to be efficiently maintained (for 20 or 30
years by someone else) and a change is required to reduce the number
of nesting levels.

Source code written using 2 character indentation and 30 indentation
levels is not something I want to maintain.

 

[Jarno A Wuolijoki]

Point in case: I was hand-hacking a Windows resource file last week.
Windows resource files use BEGIN and END. I forgot nearly all the
second-level BEGINs, because to my mind, POPUP plus indentation already
defined the beginning of the block. Using C, I hardly have to think to
just put the { at the end of the if/while/for-line.
Ok, this may be influenced by me being more used to { } than to BEGIN
END, but it's enough to show that BEGIN and END aren't inherently less
nesting-error-prone.

For an oppsite example, Today I debugged about half an hour a piece
of code that had ')' instead of '}' at the end of a block. Funny how
I hadn't realized before how similar to each other they can be made to
look like..

 

[Charlie Gordon]

For an oppsite example, Today I debugged about half an hour a piece
of code that had ')' instead of '}' at the end of a block. Funny how
I hadn't realized before how similar to each other they can be made to
look like..

Half an hour on this ???
What editor do you use ?
What is your compiler / environment ?
What was the error message at compile time ?

 

[Jarno A Wuolijoki]

Half an hour on this ???
What editor do you use ?

Ultraedit. (it probably supports brace matching but I just didn't realize
that at the moment)

What is your compiler / environment ?
gcc.


What was the error message at compile time ?

Something about some offtopic standard forbidding initialization inside
classes (I didn't say it was C..). Naturally, the error pointed to a
different source file and the main false track was that I expected
having actually put it in inside a class due to other reasons I'm not
going to enumerate here.

s/class/struct/g if feeling nitpicky. I'm fairly positive that, given
some time, I can craft a similar case in the topical language as
well.

 

[Michael Mair]

Ultraedit. (it probably supports brace matching but I just didn't realize
that at the moment)

IIRC, it does.

gcc.

Which did not give you a parse error?

Something about some offtopic standard forbidding initialization inside
classes (I didn't say it was C..). Naturally, the error pointed to a
different source file and the main false track was that I expected
having actually put it in inside a class due to other reasons I'm not
going to enumerate here.

Sounds like a problem of messy coding.

s/class/struct/g if feeling nitpicky. I'm fairly positive that, given
some time, I can craft a similar case in the topical language as
well.

Impress us:
Make
gcc -Wall -O -ansi -pedantic
compile at exactly one brace/parenthesis mismatch.

It certainly would make its way into my repository of pathological
examples.

Otherwise, you would not hunt for a bug but for a syntax error.


-Michael

 

[Jarno A Wuolijoki]

s/class/struct/g if feeling nitpicky. I'm fairly positive that, given some
time, I can craft a similar case in the topical language as well.

[...]
Otherwise, you would not hunt for a bug but for a syntax error.

Are you absolutely sure that you want to turn this into a discussion
on whether or not a failure to compile can be counted as a bug or did
you just get baited by the "if feeling nitpicky"-part?-)


Anyway, if I wanted to go on with this, I'd probably make the following
case (which I obviously don't as otherwise I'd had it written here
right after these words):

int main(void) {
#if PLATFORM_Z
int a[] = {0);
#else
int a[] = {0};
#endif
return 0;
}

Is this a syntax error or a bug? Or perhaps a bug that shows up as
a syntax error under certain conditions?

 

[Keith Thompson]

IIRC, it does.



Which did not give you a parse error?



Sounds like a problem of messy coding.

It's not surprising that a mismatched brace ('{', '}') could confuse a
compiler. It could cause the compiler to assume that subsequent code
is at a different scope that what was intended. It will eventually
detect and report a syntax error, but it could report any number of
confusing semantic errors first. (No, I don't have an example.)

 

[Michael Mair]

It's not surprising that a mismatched brace ('{', '}') could confuse a
compiler. It could cause the compiler to assume that subsequent code
is at a different scope that what was intended. It will eventually
detect and report a syntax error, but it could report any number of
confusing semantic errors first. (No, I don't have an example.)

My point was rather that Jarno A Wuolijoki called it a bug
which implied (for me) that the whole thing compiled and
the program did some kind of work.
The "messy" referred to the fact that a different source
file was implied. This usually happens only if the error
occurred in a header file. Thus, the header file was not
checked for errors and not even included into some sort of
test translation unit which includes all the headers to
check for syntax errors in the headers.
<OT>
On errors like that, gcc usually dies with a parse error.
On parse errors, you easily can check where the whole
problem occurs by commenting out large chunks of code
until it runs. If the whole payload of the translation
unit is gone, then you move on to the headers. Why waste
time with unstructured searching when you cannot spot
the reason for the error at once?
</OT>

As one can see from the example brought by Jarno A
Wuolijoki, it was not a bug we were talking about but
a syntax error. Happens to me, too. My objection was
rather to the term bug. }/) mismatches happen just like
other syntax errors and can be found easily.


Cheers
Michael

 

[Keith Thompson]

My point was rather that Jarno A Wuolijoki called it a bug
which implied (for me) that the whole thing compiled and
the program did some kind of work.

[...]

Some of us (presumably including Jarno) have a more expansive
definition of "bug".

 

[Michael Mair]

My point was rather that Jarno A Wuolijoki called it a bug
which implied (for me) that the whole thing compiled and
the program did some kind of work.

[...]

Some of us (presumably including Jarno) have a more expansive
definition of "bug".

I go by the one from the jargonfile:

http://www.catb.org/~esr/jargon/html/B/bug.html :
"
bug: n.

An unwanted and unintended property of a program or piece of
hardware, esp. one that causes it to malfunction. Antonym of feature.
Examples: “There's a bug in the editor: it writes things out backwards.”
“The system crashed because of a hardware bug.” “Fred is a winner, but
he has a few bugs” (i.e., Fred is a good guy, but he has a few
personality problems).

[snip: Historical Notes]
"

Source code which does not compile is not exactly a program
in my book.


Cheers
Michael

 

[Chris Croughton]

It's not surprising that a mismatched brace ('{', '}') could confuse a
compiler. It could cause the compiler to assume that subsequent code
is at a different scope that what was intended. It will eventually
detect and report a syntax error, but it could report any number of
confusing semantic errors first. (No, I don't have an example.)

The following (deliberately non-indented) faulty program gives a number
of errors, on no compiler I have here does it say "you missed off a }".
On the other hand, I had to force vim (the editor I use) to not indent
it, the error was very obvious when it indented automatically.

void func(char *ptr)
{
if (ptr)
{
*ptr = 'a';
}

char buff[2];

int main(void)
{
func(buff);
}

Some compilers will give "parse error before 'char'" on the line
declaring buff, some will give "parse error before '{'" on the line
after "int main", at least one C99 compiler gives "parse error at end of
input" at the end of the file, and a C89 compiler (gcc v3 with -ansi
-pedantic) gives:

warning: ISO C89 forbids mixed declarations and code
warning: ISO C forbids nested functions

Chris C

 

[Albert van der Horst]

For an oppsite example, Today I debugged about half an hour a piece
of code that had ')' instead of '}' at the end of a block. Funny how
I hadn't realized before how similar to each other they can be made to
look like..

Standard technique for when it takes more than 5 minutes to
understand a syntax error.
(Most implementations allow this one way or another.)
Run the program through the preprocessor only, typical -E.
Then through a beautifier (cb, indent).
It pays off to have a small script in place for this. At least
for someone elses code.