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]
