Practically, you may be right. My personal coding convention
has types starting with upper case, and other symbols with
lower. A line which begins with an upper case letter is
a declaration, one which begins with a lower case letter is an
expression. Except, of course, if it begins with a keyword like
static, but the editor should highlight those differently.
I follow about same conventions. Enumerators and constants start also
with a capital for me, but that is not major issue since expressions
rarely start with enumerator or constant. However there is need to
have coloring tool when i have to review some out-house code. People
follow wide rainbow of styles and conventions.
There's still the problem of finding exactly what is being
declared in a complex declaration: I'd write something like:
Toto (* func)(...);
for a pointer to a function, for example. But in practice, such
declarations are rare. Not only because of typedef's.
Yes, there are tools that can parse it quite fully. Parsing for
compiling and parsing for editing, design aid have lot of common,
editor simply must be lot softer about if it does already compile
(unknown assume int variable, does not parse, assume type).
None of which helps if you haven't written the header yet
.
Sure. But then ... my editor underlines the suspicious words red and i
constantly see that header is not yet written. ;-)
Parsing incomplete code is a couple of orders of magnitude more
difficult than parsing complete code. Still, as you say, the
power is there today.
Yes, also it depends for what you parse. All the imaginable text that
Vandevoorde's compiler can parse and report flawless C++ is not
something an editor should accept as a good code.
