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
To: [EMAIL PROTECTED]
Sent: 15/08/02 00:32
Subject: Re: Style issues.
pietsch,
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
here.)
> 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?"
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]
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: http://www.evolution.net
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]
