I'm talking about a programming convention that is supported by the existing C language, has no associated cost, complexity or difficulty, does not make significant semantic or syntactic change to programs, is easy to learn, and yet helps to prevent a common kind of bug. So I'll assume your comparison is intended as a troll. Good one!
(For the record, though: yeah, I prefer to program in languages such as Nickle and Haskell that largely eschew pointers and their associated bugs. You should try it sometime: it's pretty nice.) --Bart On Wed, Sep 11, 2013 at 11:30 PM, patrick keshishian <pkesh...@gmail.com> wrote: > On 9/11/13, Bart Massey <b...@cs.pdx.edu> wrote: >> Well now I feel bad; I thought we had discussed this before and >> everyone was OK with it. I should revert that patch now, I guess? My >> sincere apologies for being premature. >> >> For the record, though, I totally and vehemently disagree with the >> "bad style" argument. Separating definition from declaration is bad >> style, because it makes it easier to use a variable before it has been >> initialized. Whenever possible, variables should be declared at point >> of first assignment, so that it is clear that they have been >> initialized.(If you disagree, I challenge you to go back through old >> code and see how many uninitialized-variable bugs would have been >> easily caught by this convention--it will be lots.) > > That's a really poor argument. Using that logic: Do you know how > many off-by-one, buffer-overflow, double-free, etc. bugs could be > prevented if use of pointers are removed? > > bah... > --patrick > >> Further, said >> definition should be as close as possible to the position of first >> use. This allows one to easily see the definition when trying to >> understand the code that uses the variable: a big aid to debugging and >> analysis. >> >> I know of no plausible SE case for declaring variables way up at the >> top of the block they are defined in other than tradition. It was >> originally done that way to make it easier for Fortran compilers, >> AFAIK. It's error-prone and makes code harder to read: it's a >> tradition we should enthusiastically abandon. >> >> --Bart >> >> On Wed, Sep 11, 2013 at 8:57 PM, Alan Coopersmith >> <alan.coopersm...@oracle.com> wrote: >>> On 09/11/13 08:52 PM, Daniel Stone wrote: >>>> >>>> Hi, >>>> >>>> On 11 September 2013 17:31, Mark Kettenis <mark.kette...@xs4all.nl> >>>> wrote: >>>>>> >>>>>> From: Alan Coopersmith <alan.coopersm...@oracle.com> >>>>>> Pushing the patch is easy - determining if it's our consensus to >>>>>> change >>>>>> the X.Org coding style to allow this is the hard part. >>>>>> >>>>>> Does anyone object to allowing this change to the coding style now >>>>>> that >>>>>> it's no longer a hard requirement for OpenBSD's ports? >>>>> >>>>> >>>>> It's still bad style. >>>> >>>> >>>> Yeah, I actually totally agree. >>> >>> >>> The one bit I would like to have is declarations in for/while loops, such >>> as >>> for (int i = 0; i < MAXSCREENS; i++) >>> >>> Having declarations in the middle of code blocks I can live without, >>> though >>> in a few cases it would reduce the complexity of our #ifdef nesting. >>> >>> >>> -- >>> -Alan Coopersmith- alan.coopersm...@oracle.com >>> Oracle Solaris Engineering - http://blogs.oracle.com/alanc >>> _______________________________________________ >>> xorg-devel@lists.x.org: X.Org development >>> Archives: http://lists.x.org/archives/xorg-devel >>> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> _______________________________________________ >> xorg-devel@lists.x.org: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel