Julian Elischer schrieb:
David Malone wrote:
-Do not put declarations
-inside blocks unless the routine is unusually complicated.
+Prefer declaring loop iterators in the for-statement to limit their
scope.
I usually don't like this style - I like being able to review the
variables used in a function at the top.
me too
though I've softenned a bit regarding puting variables in blocks,
I do NOT want to see variable declaration "not at the top of a block".
I find this kind of strange, because this in-beetwen makes least sense
to me: Neither are all declarations grouped together nor are
declarations nicely connected to their initialisation and their scope is
minimal.
-When declaring variables in functions declare them sorted by size,
-then in alphabetical order; multiple ones per line are okay.
+When declaring variables in functions declare them sorted in
alphabetical order;
+prefer one declaration per line, especially when pointer
declarators or +initializations are involved.
The change to prefer one declaration per line seems like an unnecessary,
except to better accomodate the declare-at-initialisation below.
the 'size' bit used to be to save space.. all the chars
would be grouped together, etc.
Today's compilers plain do not care in which order you declare
variables. Sorting them in a beneficial way for space efficiency is
better left to them (and it is a rather trivial thing to do). Also you
cannot control if more spill slots have to be inserted or some values do
not live in memory at all, so only the compiler can determine, which
order is best.
But a compiler can do more: It could coalesce the space of variables
with disjoint life ranges. But this is much harder, because you have to
properly determine the life ranges. Finding an arbitrary overestimation
is easy, but the fun starts when looking at called functions, which get
passed addresses of local variables. Also finding an optimal coalescence
for known life ranges is NP-complete in the general case. But that's
another story. (:
+Prefer initializing variables right at their declaration.
I have gone the other way on this. Unless 'const' is being used I find
I prefer to see them separately initialized.
So you like hunting in multiple places instead of having both type and
value conveniently in one place?
+This makes it easier for a reader to identify the where the value
of a variable
+originates.
yeah.. at the top of the function..
Currently only the *declaration* is at the top of the function. This
bears absolutely no relation to where the *value* originates.
+Do not reuse the same variable in a different context, delare a new
variable.
I buy this largely - though it should be applied with common sense
as usual.
hmm. I think an exception might be made for our old friends i,j,k
Especially they should be declared right where they are needed. C99 even
conveniently allows the iterator variable to be declared in the first
part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By limiting
their scope, this prevents accidently re-using stale values in a
different place or other mistakes like the following:
int i, j;
for (i = 0;; ++i) {
for (i = 0;; ++i) {
/* oops, but compiler is happy */
}
}
for (j = 0;; ++j) {
/* more */
}
vs.
for (int i = 0;; ++i) {
for (int i = 0;; ++i) {
/* warning about shadowed variable */
}
}
for (int j = 0;; ++j) {
/* more */
}
everyone knows them and what they are doing.. otherwise,yes this makes
sense.
-Values in
-.Ic return
-statements should be enclosed in parentheses.
-.Pp
This is another change that isn't worth making - style(9) has had
this rule for years and changing it because you don't think it adds
anything isn't a good reason.
amen
This is no church. I presented reasons, I do not want beliefs in return.
Also stating that it should not be changed because it was always this
way is a very slippery slope.
-Use ANSI function declarations unless you explicitly need K&R
compatibility.
+Use ANSI function declarations.
Everyone shuld be doing that already.
In new code, and in old code that they touch.
So, is this pro or contra removing the K&R-clause?
Christoph
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
