Re: What is the output of this program?
Seungbeom Kim wrote:
James Kanze wrote:
Frederick Gotham wrote:
Seungbeom Kim posted:
Alf P. Steinbach wrote:
Lack of braces, always use braces for the body of 'if' or a loop.
I guess there would exist many people who would not agree with you on
the word 'always'. If it were *always* better to use braces, then the
language would made them mandatory.
I remove redundancies where possible.
I don't use unnecessary parentheses, but rather I consult
my operator precedence and associativity table (which I
have mostly memorised).
I'll admit that I've better, more important things to attend
to than memorize long tables, or look things up in them.
You would already have memorized most of the tables when you
would have to worry about more important problems. :)
Why? I've memorized very little of the C++ precedence tables
today, and I'm constantly having to deal with more important
problems. About the only time I'd bother to even look up all of
the details would be if I were writing a compiler.
I believe every competent C++ (or C, or Java) programmer
should be aware of the operator precedence.
For some definition of aware, I would agree. I'm very aware
that different operators have different precedence, that there
are a lot of levels of operator precedence, and that parentheses
override it, so I can always get whatever I want. Beyond that, I
know that unary < arithmetic < comparisons < logic < ?:/, ,
that in the arithmetic group, multiplicative operations have
precedence over additive ones, and that assignment operators fit
in there somewhere toward the end. In particular cases, I
probably know more: things like post-fix unary having precedence
over prefix, for example. But there's no way I'm going to waste
my time memorizing all of the details, nor looking them up when
I'm not sure---I'll just throw in some parentheses. And I get
bothered when I have to look them up reading code, because the
author knew them better than I did, and didn't add the
parentheses.
Otherwise you'll fall into mistakes such as
"rdstate()==state|ios_base::badbit", or be unable to detect
such cases.
That's a well known mistake in the precedence. Well known
because it is a mistake.
I agree that you *don't have to* remove redundancies wherever
possible, and that there are cases where additional
parentheses increase the clarity, but I don't think it's
necessarily bad to write tersely. As long as it does not
violate local coding guidelines, of course.
The question is always, how terse is too terse. Terseness is a
quality, until it crosses the line into too terse.
I actually prefer the term "concise". It sounds more positive.
But I suspect that my concise and your terse are not really very
different. And the rule is "clear and concise". It's not
always easy---carelessly done, clarity leads to verbosity, and
conciseness to opacity. It's sometimes a judgement call, and
often a bit of a balancing act.
I don't use braces when all I need is one statement. If I've
two simple statments, I'll probably use a comma:
if (*p) ++p, --i;
You also won't work in any company I've worked in. They all
have coding guidelines. The exact rules vary, but
programmers are expected to conform to them. And none of
them would ever allow anything like your last example. Most
ban the comma operator entirely, but even those that don't
limit its use to specific cases.
Of course, local coding guidelines rule first, just as local
variables comes before everything outside. However, it has
been a long practice to use the comma operator for such cases,
and I wouldn't condemn this example as necessarily bad.
Has it. I must admit that I've never seen it, or even heard of
it before (outside of the IOCCC, of course). Kernighan and
Richie suggested using it in for statements, and not much
elsewhere, and the practice I've seen has been either never, or
only in conditional statements. Or, exceptionally, and only
very recently, to extend the lifetime of a temporary, something
like: "boost::mutex::scoped_lock( someMutex ),
protectedOperation()". (Although all of the coding guidelines
I've seen forbid this last use, I'm really somewhat open about
it. In some ways, it's subtle, but it does avoid an otherwise
unnecessary variable. But of course, it also presupposes
standard conformance with regards to the lifetime of
temporaries, which isn't always the case.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]