Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: "...the value becomes,indeterminate each time the declaration is reached" Date: Thu, 07 Mar 2019 11:24:00 -0800 Organization: A noiseless patient Spider Lines: 112 Message-ID: <867edatrn3.fsf@mailhub.linuxsc.com> References: <20190201132441.0b099e5f38fdb72371bc44f0@g{oogle}mail.com> <87k1i3i8un.fsf@bsb.me.uk> <87o97egvvs.fsf@bsb.me.uk> <878syigt18.fsf@bsb.me.uk> <87y36if4nv.fsf@bsb.me.uk> <868sy3cdbp.fsf@mailhub.linuxsc.com> <87imx61vq7.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d3b01caac7c628c5d4cb6d0252dc8c88"; logging-data="29065"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18aAfU0RIqWikdVr/233qLmBq6u6tB81lY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:JKkNqUsoL9X2WP/WlhWORmYH8zc= sha1:SK1UAuvWGoZNufWreq3OfCyhWTw= Xref: csiph.com comp.lang.c:141790 Ben Bacarisse writes: > Tim Rentsch writes: > >> Ben Bacarisse writes: >> >> ... >> >>> My coding style (when not constrained by cooperation) appears to >>> be widely disliked. > > (I was talking about C, of course) > >> Well that has me curious. Can you say what about your style >> choices people dislike? Or post a small example (perhaps >> with commentary)? I'm always interested to learn what >> people react to. > > I've probably forgotten many, but > > (a) I like using multiple declarators in one declaration to collect > related objects: > > double dest[SIZE], *dp = dest, *ep = (&dest)[1]; I'm completely with you on this one. > (b) I don't mind using slightly obscure parts of the language if it > seems right, like using (&dest)[1] above to avoid duplicating the > use of SIZE. The construct (&dest)[1] is a charming idiom. Every serious C programmer should have that in their toolbag. Although, I'm having trouble thinking of another example in this category (ie, that you might be thinking of). Can you give another example or two? An idiom I use now and then, and which I'm sure some other people would just hate, is 0[pointer-expression], to access the value pointed to by the expression. I find the []'s help me chunkify the expression more easily (ie, in some cases), than the similar form using * and parentheses. > (c) I don't like unnecessary {}s. I remove them when I find a compound > statement has only one statement in it, and I put them back if > editing adds more: > > void selection_sort(int n, T A[]) > { > for (int i = 0; i < n - 1; i++) { > int min = i; > for (int j = i + 1; j < n; j++) > if (less_than(A[j], A[min])) > min = j; > swap(&A[i], &A[min]); > } > } I don't know what to make of this preference. I don't strongly mind the braces being left off for small bodies (although I don't do that myself), but for larger ones it seems wrong. Do you think this is just because this is what you're used to, or is there some other motivation/benefit that is driving this? When there is a single controlled statement that fits on the same line as the controlling part, I often choose to write both parts together (and without braces) on a single line. I pretty much always do this in the case of if() and some sort of control transfer statement - break, continue, goto, or return. But that's not the same as what you're saying. > (I'd /like/ to be able to do this for function bodies too! The > function above has only one statement in the body, but I am forced > to write it in {}s. I think this last point comes from taking too > much BCPL in my youth.) Every programmer can have any single statement to define the body of any function definition, as long as that statement is a compound statement. (paraphrasing Henry Ford dictum about car color.) > (d) Ditto ()s in expressions. I don't always use minimal bracketing, > but some extra ()s annoy me. && binding more tightly than || seems > so natural to me that I don't like reminding myself with extra ()s. Yeah I am fully on board here. > (e) I have no qualms about some side-effects in expressions. Not sure > exactly which are OK with me and which not, but the odd > > while ((c = *ptr++) != target) ... > > is certainly fine in my book. Right. The key point is that some patterns are fine but there is a line that is important not to cross. I'm not sure what this means as it pertains to teaching new students. > [... algol 68 related ...] > > As I say, there are probably loads more. The point is that pretty much > every one of these has been met with opprobrium here at some time or > other. Nothing wrong with that of course. I think that depends on how much substance was offered, and how much of the reaction was just "euuw, this is not what I'm used to."