Date: Tue, 1 Feb 2005 13:23:04 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Paul Richards <paul@originative.co.uk> Cc: arch@freebsd.org Subject: Re: c99/c++ localised variable definition Message-ID: <7133afbc3492c934b5686c5e6f0911b1@xcllnt.net> In-Reply-To: <20050201204331.GH61409@myrddin.originative.co.uk> References: <20050128173327.GI61409@myrddin.originative.co.uk> <20050131102630.GJ61409@myrddin.originative.co.uk> <20050201180624.GB19624@funkthat.com> <20050201190416.GG61409@myrddin.originative.co.uk> <fa820cbe585add3bebb31954175460f3@xcllnt.net> <20050201204331.GH61409@myrddin.originative.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 1, 2005, at 12:43 PM, Paul Richards wrote: > On Tue, Feb 01, 2005 at 12:30:37PM -0800, Marcel Moolenaar wrote: >> On Feb 1, 2005, at 11:04 AM, Paul Richards wrote: >> >>>> And wonder why i gets such a strange value... It appears that >>>> unless >>>> you have WARNS=4 set, warnings about: >>>> t.c:10: warning: declaration of 'i' shadows a previous local >>>> >>>> don't show up. So, I would say we HAVE to get the tree building >>>> with >>>> WARNS=4 and -Werror before we let this into style(9)... >>> >>> The issue with shadowing outer scope variables is only an issue if >>> you need to access them. If your only using the syntax for loop >>> variables to do the looping then there's no issue. >> >> Never forget that you want to be able to debug you application. >> While technically you're right, it's bad practice to do so. > > I disagree with this point. I think it's more error prone to rely on a > side effect of a loop variable to exist outside the scope of the loop. There's no side-effect. You define it outside the loop. You know that the scope will be larger than the scope of the loop itself. The only down side is that the life-range spans the whole function and not the one loop it is used in. *cases snipped* It's all subjective and very much dependent on the context. There are indeed times when localised variable definitions are in fact more elegant. But it doesn't go beyond just being more elegant. It doesn't add to the power of the language. It just addresses one of many down sides in this particular language (and every language has plenty of down sides) that you could just as well have solved with #pragma statements or lint(1) annotations. It does however introduce more ways to make mistakes and I simply don't value elegancy that much. I value consistency more. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7133afbc3492c934b5686c5e6f0911b1>