J.Pietschmann wrote:
> 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).
It comes from reading code. If you have been writing C code for years,
the first idiom is actually easier to follow. I suppose you could say,
if you needed such a crutch, that it was a pattern.
>
>>> 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).
Let's call them guidelines, especially as they don't need to be
enforced, and more especially as they cannot be. 1 and 2 are like the
others, in that they tend to appeal to the aesthetic sense, and code
that is aesthetically appealing will usually be found to work better.
This is not a rule. It's not even a guideline.
I can't imagine that anyone, as he codes, ticks off a checklist of style
rules. It's a matter of habit and example. One reads suggestions like
Joerg's above and decides that, yes, that's a good idea, and it becomes
part of one's personal armoury of techniques.
But they remain, I hope always, personal. I _want_ to be able to pick
up code and say, ah, that's Keiron's, that's Karen's, without having to
look for an @author. Back in the mists of time, I did a few subjects in
CS at UofQueensland. When I picked up a Fortran assignment from the
lecturer, he commented that I'd been programming for some time. I had.
"You have a certain style." My experience was recognisable in my
code. The maker's mark is not the signature in the corner, it's the
work itself.
This, it seems to me, is one of the engines of open source development,
and why there are so many anarchists, like esr, involved, and why those
detestable red stars are plastered all over mozilla. If we keep that in
mind, we might not throw the baby out with the bathwater.
> 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.
It comes down to "ugliness", doesn't it? "camelCase" is nice. I
haven't heard it before, and I agree with your admonition.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
