Karen Lease wrote:
>> if ((bp = getNextBreakPoss(childLC, null)) != null) {
> Probably comes from long years of writing C and C++ and avoiding extra
> lines of code. Must be taste since I don't find it that bad, but if we
> all vote it out in the style rules, I'll agree to banish it!
It comes from reading code: first recognize the
control flow, which is fortunately easy now, then
get the assignments. Assignments buried in other
expressions make this harder.
As for:
while ((curLM = getChildLM()) != null) {
well, this avoids writing the assignment twice.
Nevertheless, if it's an iteration, why not use
a more iterator like pattern:
while (hasNextLM()) {
curLM = nextLM();
(Unfortunately, the sample code before this represents
*not* a proper iterator pattern, which I actually find
quite misleading).
>> 3. Exceptions
> Agreed, it would be better to recheck super.hasNext() rather than
> letting it throw the exception. However, you'll note that the exception
> is only propagated from this method in the case where it's hasNext()
> returns false, which is the normal behavior for an Iterator.
It's not the case where the exception is rethrown, it's
the regular case.
>> 6. ...hungarian notation.
> Like most everyone else that's responded, I say, let's just pick a rule
> that makes it clear what are member or static variables and which are
> local and stick to it. Personally I tend to prefer m_xxx to this.xxx,
> with or without hungarian.
From my experience, rules demanding to encode the scope
of a variable in it's name are doomed for the same reason
hungarian notation is:
1. You will have enough people hacking around in the code
who don't like it or don't care or simply feel in a
hurry.
2. It happens that a variable is moved from one scope to
another. You can bet that if the variable is referenced
more than twice, it wont be renamed. While this is
certainly much rarer than people generally assume,
it is probably the reason *why* people don't like
rules for encoding scope or type in names. It feels
like a severe restriction.
Let's apply common sense:
1 If you introduce a variable, use the smallest scope which
will do the job.
2 Don't reuse the same variable for different things.
3 If the scope is reasonably small, declare a local
variable just before it is used. Otherwise declare it
at the beginning of the block which contains the scope.
4 Declare instance variables at the beginning of the class.
5 Declare class variables before instance variables.
6 Don't litter variable declaration blocks with unnecessary
comments and empty lines. Use longer names if possible.
Comment only blocks with block comments. Comment
individual declarations with endline comments only.
7 Avoid both large functions as well as lots of small
private functions which are used only once or perhaps
twice. This does not mean functions of 300 lines length
should not occur, it means such functions should not occur
too often, and declarations for local variables should be
placed wisely.
Interestingly, there is no need to enforce the rules 3-6.
Moving a bunch of lines is much easier than to rename a
variable (because you don't have spurious matches to
check), so someone *will* find variable declarations
buried at arbitrary places ugly and move them where they
usually look for variable declarations. Of course it is
an advantage if there are already examples there...
The result of such simple rules: If you look at some code,
and there is an unqualified variable, center it in the
editor window and either you see the declaration already,
or you have to scroll up one or two screens to get near the
function header, or you have to search near the beginning
of the file (you'll probably know after a few tries which
files have huge comment blocks at the beginning).
The only encoding rule I'd realy like to have:
Don't mix underscores with camelCase.
Beside looking *really* ugly, it screws up Emacs' dynamic
identifier completion, and I'd rather like to do
something for FOP than fixing this.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
