J
James Kanze
It's not contentious, but it does need to be consistent, and to
be consistent, it needs to be part of the coding guidelines.
It's not contentious, but it does need to be consistent, and to
be consistent, it needs to be part of the coding guidelines.
J
James Kanze
Or some other formatting as well. To format C++ (or any other
language) well, you really have to understand the language.
None of the editors I've used are good enough to get it right
all the time.
What's important is that everyone formats the code the same way.
Certainly (at least these aspects of a standard). But keeping
people from being annoyed is important.
Not as big a deal. They're still important, just not as
important as some other stuff. (Up to a point. If your
indentation is no indentation---every line starts in the same
column, then it is a serious problem.)
That's not a good coding guidelines, then. The rule #0 should
always be: "any rule in this guideline can be violated if there
is a justification for it".
C
Christopher Dearlove
James Kanze said:
The usual example of a "termination may not be a good idea" is
a word processor spell-checker. If the spell-checker gets itself
in a knot, terminating the spell-checker may be great - but I'd
rather the word processor didn't terminate, and certainly not
without saving (but probably not on top of the original) my
document.
C
Christopher Dearlove
That's Sutter's and Alexandrescu's book.
N
Noah Roberts
James said:
If you say so, it must be true, right? Why justify anything?
Maybe that's why I've never seen such.
N
Noah Roberts
Christopher said:
It's not a good coding guideline. It spends too much time covering
material like RAII and other guidelines that actually affect the
operation of the code. The should spend more time on formatting so that
everyone knows exactly where to put the ';'. They have their priorities
all fucked up.
A
Alf P. Steinbach
* Noah Roberts:
He he.
That could explain problems at Microsoft? With Herb as chief
architect there? I don't have it but I've read some of it (on the net)
including the table of contents. And on that basis I think it provides a /very/
good counter-weight to all the guides focusing only on personal preference
stylistic issues and thereby being more obstacles than being helpful.
There's one problem that I know.
Namely that somewhere in there they advocate using conversion via void* instead
of, when needed, proper reinterpret_cast, without any rationale (and at least on
the surface that seems like just dumb, totally misguided advice).
But apart from that, on the basis mentioned above I think it's great, and it's
my impression that it's generally recognized as great, in the rôle of
counter-weight or primary guide to be supplemented by details.
The ideal for the common programmer is probably somewhere in-between, a little
more focus on e.g. naming things and a little less high-level advice which is
difficult to check and so would better be placed in "Effective C++"...
Cheers,
- Alf
He he.
That could explain problems at Microsoft? With Herb as chief architect there?
I don't have it but I've read some of it (on the net) including the table of contents. And on that basis I think it provides a /very/
good counter-weight to all the guides focusing only on personal preference
stylistic issues and thereby being more obstacles than being helpful.
There's one problem that I know.
Namely that somewhere in there they advocate using conversion via void* instead
of, when needed, proper reinterpret_cast, without any rationale (and at least on
the surface that seems like just dumb, totally misguided advice).
But apart from that, on the basis mentioned above I think it's great, and it's
my impression that it's generally recognized as great, in the rôle of
counter-weight or primary guide to be supplemented by details.
The ideal for the common programmer is probably somewhere in-between, a little
more focus on e.g. naming things and a little less high-level advice which is
difficult to check and so would better be placed in "Effective C++"...
Cheers,
- Alf
P
Phlip
Noah said:
To be a team, the individuals should match each others styles and expectations.
The code should read as if one (very smart) person wrote it.
The justifications are technical - the code has better odds to work right
together - and psychological - you are more likely to change the code you need
to change without worrying about stepping on others' toes.
The "justification" is exactly the same as shaving new military recruits' heads.
To defeat aimless individualism. (Note that _aimful_ individualism is the _goal_.)
N
Noah Roberts
Alf said:* Noah Roberts:
He he.
architect there?
net) including the table of contents. And on that basis I think it
provides a /very/ good counter-weight to all the guides focusing only on
personal preference stylistic issues and thereby being more obstacles
than being helpful.
There's one problem that I know.
Namely that somewhere in there they advocate using conversion via void*
instead of, when needed, proper reinterpret_cast, without any rationale
(and at least on the surface that seems like just dumb, totally
misguided advice).
They provide rationale: "...reinterpret_cast isn't even guaranteed to do
that or anything else in particular."
In discussion:
"Besides, the reality is that reinterpret_cast's effects are worse than
reinterpreting objects' bit patterns (which would be bad enough).
Except that some conversions are guaranteed to be reversible, its
effects are actually implementation-defined, so you don't know if it
will do even that. It is unreliable and nonportable."
They don't go on to explain how statically casting to/from void* is
specified by the standard to work. It would make their argument
stronger. The only thing they recommend casting via void* is unrelated
pointer types. They do mention that there are some exceptions, such as
transforming integers into addresses.
This book is more like an Effective C++ style book though. Almost
exactly the same format even.
A
Alf P. Steinbach
* Noah Roberts:
It would perhaps make the argument less stupid.
There's no more guarantee with void* as middle-man, than with reinterpret_cast.
On the contrary, it hides the conversion (not a good idea!) and makes it
difficult to search for, and it introduces the void*, making it more probably
that it will be passed around, which is very ungood, so it's jus' plain stupid.
Cheers & hth.,
- Alf
It would perhaps make the argument less stupid.
There's no more guarantee with void* as middle-man, than with reinterpret_cast.
On the contrary, it hides the conversion (not a good idea!) and makes it
difficult to search for, and it introduces the void*, making it more probably
that it will be passed around, which is very ungood, so it's jus' plain stupid.
Cheers & hth.,
- Alf
N
Noah Roberts
Phlip said:
I don't see any technical justification here. How, exactly, did you
measure the odds of the generation of operational code based on team
solidarity about where to put the semicolon? What, exactly, are those odds?
P
Phlip
Noah said:
Do you demand the same level of justification for all your technical decisions?
N
Noah Roberts
Phlip said:
Expect a slight bit more than baseless claims about odds that were never
measured or analyzed. As should you.
P
Phlip
Noah said:
Okay. Everyone write code a different style from your teammates.
C
coal
"There are rules behind the rules and a unity that is deeper
than uniformity." C. S. Lewis You remind yourself of this
though later in your post. It just needs to be applied here
as well. If there's a unity of spirit, this stuff isn't
a problem. That unity is almost non-existent today on large
projects, and uniformity as you suggest is substituted. It
is, of course, an inadequate substitute.
Not more important than fighting for what you believe in.
Yes, except it's rule #1.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net