Sujet : Re: how to make a macro work as a single line if stmt without braces
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 30. Sep 2024, 10:26:31
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vddqs8$266ki$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
First, I want to re-emphasize that valuation of styles lies in the
eye of the beholder. Then, for practical purposes, there's usually
(coding-)standards defined [in professional contexts] that define
the rules folks have to follow. While in private contexts everyone
is free to follow own personal preferences.
On 30.09.2024 04:29, Kaz Kylheku wrote:
[...]
For what it may be worth, the K&R style is pretty much baked into the
Awk language. These two Awk programs are not equivalent:
/foo/
{
foo++
}
vs:
/foo/ {
foo++
}
For the readers unfamiliar with Awk it should be mentioned that
this is a consequence of Awk's implicit defaults.
/foo/ is equivalent to /foo/ { print $0 }
and
{ foo++ } is equivalent to 'true' { foo++ }
(using the informal 'true' as placeholder for any true condition).
Thus you have to put the opening braces on the same line as the
condition to indicate that condition and action belong together.
[...]
It is an undeniable fact that alignment and grouping is important
in visual design, and that use of these elements (and others)
is important in creating signs and displays that are easy to
grok at a glance.
Sic!
[...]
Also, I can see how the structure is more nicely conveyed when the
eopening braces are indented, if the reader temporarily blocks out
the visibility of the code and focuses on only seeing the braces:
This:
{
{
{
}
}
}
{
}
As far as I'm concerned, it's not only the braces but also the
placement of the associated control-structure keywords that
matters.
To _quickly_ *assert* the code structure the following...
versus:
{
{
{
}
}
} {
}
...is indeed [unnecessarily] suboptimal! (And adding the keywords
doesn't make that situation better.) Having tool support (like
an editor's syntax highlighting) might alleviate that issue (but
does not solve it).
(Maybe it's to some degree comparable with the difference between
ragged layout of texts vs. text that has consistent line lengths
or is even block-justified.)
In other words, the vertical braces enable a mode of visually filtering
the code that may be of use to some. (Though, to me, choosing to see
the braces while suppressing the rest of the code seems wrongheaded. Or
wrong-eyed?)
There's nothing suppressed. (Moreover I think any tries to value
other preferences with psychological assumptions and personal
valuations doesn't serve the discussions.)
BTW, a friend of mine (a long year experienced CS professional)
prefers [to my astonishment] a formatting I've not (or certainly
not widely) seen before...
while (cond)
{
stmt1;
stmt2;
}
Also aligned (but differently).
[...]
It might make sense - besides visual or "psychological" explanations -
to also include people's experiences with or influences from other
programming languages they use. People may be used to structures like
if condition then
begin
...
end
else
...
which can be found in many languages (Algol, Pascal, ...), or from
the Unix [standard] shell where syntax requirements foster structures
like
if command1
then
command2
else
command3
fi
My personal preferences are best supported by a syntax that you
find in Algol 68, Eiffel (or Unix shell), where you usually don't
need any sort of brackets in control structures, and where there's
thus less dispute about where to place the 'opening block' symbol.
Janis