Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: gcc needs a curly bracket matching/counting function Date: Wed, 21 Dec 2016 09:04:19 -0800 Organization: None to speak of Lines: 97 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="e647705ee050c178d8090e6d328af466"; logging-data="26696"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18dR9Jgl7qbgek2LiyOxfnW" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:+f9WO9Zlomw8zJLROpeGKsqsWyY= sha1:GOlpQufagImEYplJdyhdwa45r6Y= Xref: csiph.com comp.lang.c:99993 BartC writes: > On 21/12/2016 11:07, David Brown wrote: >> On 20/12/16 14:35, Rick C. Hodgin wrote: >>> On Tuesday, December 20, 2016 at 8:20:47 AM UTC-5, Bart wrote: >>>> On 20/12/2016 03:30, DFS wrote: >>>> >>>>> I'd rather the compiler do at least a quick count for me. >>>> >>>> The compiler is handicapped by the language. This has the right number >>>> of { and } braces and compiles fine: >>>> >>>> if (a) { >>>> if (b) >>>> puts("B1"); >>>> puts("B2"); >>>> } >> >> C gives you the ability to write code in an ugly, confusing and >> error-prone manner. So do all programming languages I have ever seen. > > In the syntax I normally use, this example is impossible to write > without invoking an error. That would be some other language than C, right? >> The details of how you can write confusing and bad code with legal >> syntax varies from language to language, but it is always possible. >> >> You avoid this particular problem with a simple rule - a for, if or >> while statement should always have brackets. > > Unfortunately that doesn't always work, as the language won't not cooperate. Sure it does. It doesn't always diagnose failures to follow that rule, but it doesn't get in the way of following it yourself. > If you forget the braces, it won't tell you as it knows nothing about > your rule, unless it can't match them. You can also put in extra braces, > and that's OK provided the extra brace is matched elsewhere. So don't do that. > It doesn't help that the same } brace can close an if-block, for-block, > while-block, do-block, switch-block, function-block, a data-block, and > just a block-block. I've never found that to be a problem, as long as I use braces consistently -- which is not at all difficult to do. (I sometimes have some difficulty when I'm working on code written by others. Such is life.) > So it's a language design issue; it's not true that all languages are > the same. Not regarding this block-delimiting anyway. Did anybody say that all languages are the same? Perl, for example, requires braces on all compound statements. (Personally, that's one thing I like about Perl.) But if Perl didn't require braces, I'm entirely capable of using them anyway, just as I do in C. > And people aren't going to follow the rule as it's far too tempting to > just write: > > if (!fp) return 0; > > (leaving this open to brace-matching and dangling else problems). In fact, a lot of people *do* follow the rule. I sometimes (rarely) omit braces on one-line statements. It doesn't cause brace-matching or dangling else problems, because I consistently use braces on multi-line statements. > And you need a consistent >> bracing and indenting style - I recommend the One True Brace Style as a >> starting point, but variations are possible. > > Yes, everyone uses /their own/ consistent style! Yes, the lack of consistency of brace styles can be a problem. Pick a style and follow it consistently for your own code (I like the 1TBS, but I don't complain if you prefer something else). If you're working on existing code, consistently follow that code's existing style. Once again, you seem to be inventing problems just so you can complain about them. The solution to this particular problem is not "change the language, breaking decades of existing code, so the compiler will diagnose missing braces". The solution is "exercise a bit of discipline when writing code". -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"