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]