Related articles |
---|
[6 earlier articles] |
Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-05) |
Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-05) |
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-06) |
Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-07) |
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-08) |
Re: another C-like language? was Compilers :) DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-01-09) |
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09) |
Re: another C-like language? was Compilers :) Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-09) |
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-10) |
Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-10) |
Re: another C-like language? was Compilers :) tkoenig@netcologne.de (Thomas Koenig) (2023-01-11) |
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-11) |
Re: another C-like language? was Compilers :) findlaybill@blueyonder.co.uk (Bill Findlay) (2023-01-11) |
[9 later articles] |
From: | Kaz Kylheku <864-117-4973@kylheku.com> |
Newsgroups: | comp.compilers |
Date: | Mon, 9 Jan 2023 17:41:51 -0000 (UTC) |
Organization: | A noiseless patient Spider |
References: | 23-01-001 23-01-002 23-01-003 23-01-008 23-01-016 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="32133"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, design |
Posted-Date: | 09 Jan 2023 21:34:36 EST |
On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
> don't want to go through them all, but I agree with you that the style
> of "all your declarations at the start of the function" is long
> outdated, and often - but not universally - considered a bad idea.)
Declarations have never been required to be at the top of a function in
C, because they can be in any compound statement block. I think
that goes all the way back to the B language. [Nope, see the next message. -John]
The "Variables at the top" meme may be something coming from Pascal.
IIRC, in Pascal, compound statements aren't full blocks; they cannot
have VAR declarations.
When programmers abandoned Pascal in the 1980s, they carried over this
habit into C.
I hate mixed declarations and code because it's almost sa bad as
variables-at-the-top. The scope of a declaration that is just planted
into the middle of a compound statement block extends all the way to the
end of the block. There should be a smaller enclosing block which
exactly delimits the scope of that variable. If some variable is used
over seven lines of a 300 line function, those seven lines should
ideally be enclosed in curly braces, so the variable is not known
outside of those lines. Just planting an unwrapped declaration of the
variable at the function scope level (outermost block) solves only half
the problem. The scope of the variable starts close to where the
variable is used, which is good; but it still goes to the end of the
function, way past its actual semantic scope that ends at the last use.
A block like this can be repeated with copy and paste:
{
int yes = 1;
setsockopt(fd, SO_WHATEVER, &yes);
}
This cannot: you will get redefinition errors:
int yes = 1;
setsockopt(fd, SO_WHATEVER, &yes);
you have to think about ensuring that "int yes" occurs in one place
that is before the first use, and the other places assign to it.
Or invent different names.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
Return to the
comp.compilers page.
Search the
comp.compilers archives again.