C99 Features

Theodore Ts'o tytso at mit.edu
Tue Jun 16 10:59:41 EDT 2015


On Tue, Jun 16, 2015 at 01:20:51AM -0400, Greg Hudson wrote:
> * Our style guide discourages declaring variables in interior scope.
> The justification (which predates my involvement) has to do with
> debugging convenience and limiting function complexity; I personally
> find that code is a little easier to read if it doesn't have type
> declarations mixed in with statements.  If there are good reasons to
> avoid interior scope declarations, those reasons may also apply to mixed
> declarations and code.
> http://k5wiki.kerberos.org/wiki/Coding_style/Practices#Local_variables

This one is my fault, and dates back to a time when gdb would
completely fail to allow you to examine at variables that were not
declared at the beginning of a function.  This made debugging problems
to be quite painful, to say the least.  This has been fixed with
modern versions of gdb, so the original reason why I had promulgated
that rule was long gone.

Limiting function complexity is still a good reason, which is why some
coding practices will use an 8 space tab stop and 80 column line
width, and point out that if you're indenting more deeply than three
or four tab stops, you should seriously rethink whether the function
should be refactored.  But as a reason for itself, I don't think it's
strong enough to support such a rule, since as Greg points out, there
are some good reasons for declaring variables inside a narrower scope.

Looking at the Kerberos Wiki (which postdates my involvement), I see
that it now points out that the gdb restriction might still be the
case on Solaris.  I'm not sure whether or not that is true, since
blessedly my responsibilities these days allow me to pretend that
Solaris doesn't exist and doesn't matter.  :-)

In any case, it's up to those whose hands who now have stewardship for
Kerberos to decide whether or not any particular part of the style
guide still makes sense, but I thought adding a bit of historical
color might be helpful.

Cheers,

						- Ted


More information about the krbdev mailing list