Regarding 1. Tabs:
 I've worked on a project with someone (Dale, cc'd) who set up the project
CVS store to not allow checkins of source containing tabs.  The server would
return a polite message telling the developer to change the tabs to spaces
and try again.
 Well be worth doing if you are happy to force this on people rather then
just ask nicely.

 This was probably easy to set up (I don't know how to set CVS up), but Dale
I'm sure will say what he did if it was difficult at all.

 - Keith

-----Original Message-----
From: Peter B. West
Sent: 15/08/02 00:32
Subject: Re: Style issues.


Style judgements are a very personal matter.  Personal tastes follow.

J.Pietschmann wrote:
> 1. I'd appreciate if indentation uses spaces instead of
>    tabs. And because I can avoid using tabs, I expect
>    everyone else avoiding tabs too.

This is pretty much a necessity because of the potential variability of 
tab expansion.  I've wanderered unknowingly into code written with hard 
tabs set to 2 spaces.  In many long years, I have _never_ changed the 
tab default, but other people do.  Having your editor substitute spaces 
makes for compatibility.

> 2. I'd really, really appreciate if assignments were
>    not made operands of other expressions, especially
>    not operands of comparisions in if statements:
>     if ((bp = getNextBreakPoss(childLC, null)) != null) {
>    I'd make some exceptions for more commonly used idioms
>    in while statements
>       while ((curLM = getChildLM()) != null) {
>    but IMO this still s*cks.

Oh dear.  I do it all the time, particularly with the latter idiom, 
which is awkward to avoid.  I can see the argument for avoiding the 
first, although it is a very deeply ingrained habit with me.

> 3. Exceptions should never, ever replace simpler flow
>    controls:
>      try {
>         return super.nextChar();
>      }
>      catch (NoSuchElementException e) {
>        if (bEndBoundary) {
>           bEndBoundary=false;
>           return CharUtilities.CODE_EOT;
>         }
>         else throw e;
>      }
>    Apart from the potential for confusion, throwing
>    exceptions is an expensive operation and should really
>    be reserved for rare and non-local exits.

No argument from me.

> 4. Some identifiers make me a bit uneasy, like "BreakPoss".
>    IMO random abbreviations should be avoided unless the
>    identifiers become really long and unwieldy, at least
>    in class names and preferably also in method names.
>    Furthermore, I think abbreviations should be used
>    consistently at least across class and method names:
>      public void setStructHandler(StructureHandler sh) {
>      public BreakPoss getBP() {
>      protected Position getPos(Object nextObj) {
>    Is it really worth to save a few characters this way?
>    Also, capitalization should be consistent:
>      class LMiter
>      interface BPLayoutManager

An interesting illustration of your argument.  BreakPoss is a break 
possibility, not a break position.  The problem with setting 
verbosity=full is that lines can get very long, and one ends up with 
multiple breaks in the line.  (Yes, a number of other discussions arise 

> 5. I don't think naming styles should be mixed without good
>    (and preferably explained) reason:
>      boolean m_bInited = false;
>    Yuck!
> 6. There seems to be a drive to use hungarian notation.
>    While I don't have a strong feelings for or against it,
>    I'd like to note that in all projects I've watched such
>    an efford was ultimately wasted. Usage universally
>    degraded over time, and causal and inconsistent usage
>    just makes the code look ugly.

I think the horse has already bolted on this one.

> 7. I think a bit more time should be spent to check general
>    consistency after wholesale copy&paste:
>       /**
>        * This is the top level layout manager.
>        * It is created by the PageSequence FO.
>        */
>       public FlowLayoutManager(FObj fobj) {
>    Well, bad things happen.

Good idea, but we can hardly go crook at anyone who misses something 
like this.  However, if one is about to engage in a wholesale c&p, it is

probably worth asking, "Is there a better way?"

"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Evolution is the investment banking and venture 
capital industry's first choice for practical advice 
on strategy, business process and the application of 
advanced technology. 

Evolution                Tel:     +44 (0) 20 7664 6640 
Peninsular House         Fax:     +44 (0) 20 7664 6641 
30-36 Monument Street    
London EC3R 8LJ          URL: 
United Kingdom 
The information in this Internet e-mail is confidential 
and is intended solely for the addressee.  Access, 
copying or re-use of information in it by anyone else 
is unauthorised.  Any views or opinions presented are 
solely those of the author and do not necessarily 
represent those of Evolution or any of its affiliates. 
If you are not the intended recipient please contact 
Evolution, London, +44 (0) 20 7664 6640 

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to