Re: More style issues
Jeremias Maerki wrote: But I'll never define a variable called blockProgressionDimension! I was after weirder stuff. Some random picks: - availIPD (but availableBPD used elsewhere) - avgWidth (but averageLineLength used elsewhere) - bHyph (but hyphen/hyphenate/hyphenation used lesewhere) - bInWS - bSuppressLastPar - backProps (but backgroundNNN used elsewhere) - baseProp (but baseProperty used elsewhere) - bfentries - bpdim - bufin - cbout - cfvals - cmpnValue - contentPosIter (but contentListIterator used elsewhere) - curCharIter, but currParIterator - curTxf - currentGU - currentPageG - currentPageNum (but currentPageNumber used elsewhere) - currentloc - cycenum - dbuf - decoData - defG - descPList: description? descendant? descartes? - dur - effBorders (but effectiveAlignment used elsewhere) - elem (but element used elsewhere) - embFile (but embedFile used elsewhere) - equivChar - errMsg - etmXHeight - extGState - fnSeparatorLength (but footnoteNNN used elsewhere) - getAllocIPD (but getAllocationIPD used elsewhere) - getBBox - getCCL - getColSpanIndex (but getColumnRowSpanningAttrs used elsewhere) - getCurrentPV - getKE - getLM (but getLayoutManager used elsewhere) - getLsb - getP - getRefIPD (but getReferenceAreaIPD used elsewhere) - getSPM - getStemV - grn - guSpan - hasTextDeco - horzSpan - htPropNames - iTWSadjust - inl - intbl - ipdWidth (ultimate weirdness!) - kpx1 - lastLoca - leadingSS - ledd2 - longHorMetricSize - lvlInCntr - mtxPtr - myShad - numLen - offDocumentItems - paddingPt - pgNbField - pixSzMM - propEx - relbase (but relativebase used elsewhere) - resSpace: reserved? resolved? reset? randomly enhanced space? - rightPadStr - rslt - setDW - setDoOutput - sPM - spMaker - trIter - transFactory - uniMap - xRefFormats HTH J.Pietschmann
Re: More style issues
On Fri, Sep 09, 2005 at 08:38:18AM +0800, Manuel Mall wrote:
On Fri, 9 Sep 2005 07:55 am, J.Pietschmann wrote:
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
+1 I am with you here - allthough I am guilty as well: If I find a class
written in hungarian style and I have to make a modification I will
sick with the style of the original author. What I dislike most is
mixing styles as this make code IMO very difficult to read.
Hmm, if I remember FOP code uses b and i for boolean and int, and I
have added to that usage. I do not have a problem with it. It may not
add information, but I like the fact that it carries type info with
it. It certainly does not bother me.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
Doesn't worry me too much although I prefer the style you prefer as
well.
That is my position as well.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
That's a difficult one - I don't think there is a right or wrong here.
And yes consistency would be great (e.g. all layout manager classes
should be called ...LayoutManager and not some ...LM). I agree that
this is not really a typing issue but it is arguable at what length an
identifier actually gets in the way of readability, e.g. is
'lineStartBorderAndPaddingWidth' preferable to 'lineStartBAP' if that
variable is used a lot in expressions which are then split over multi
lines everywhere this variable is used?
What about a WIKI page listing commonly used abbreviations found in the
code base?
So +1 for consistent class names and +1 for consistent and considered
use of abbreviations but please don't ban them altogether.
I feel the same way.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: More style issues
+1 to all three points. But I'll never define a variable called
blockProgressionDimension! That's always going to be bpd for me, but
then ipd and bpd are so omnipresent so it shouldn't be a problem.
Exceptions prove the rule, don't they? :-)
On 09.09.2005 01:55:06 J.Pietschmann wrote:
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
Regards
J.Pietschmann
Jeremias Maerki
Re: More style issues
Jeremias Maerki wrote: +1 to all three points. But I'll never define a variable called blockProgressionDimension! That's always going to be bpd for me, but then ipd and bpd are so omnipresent so it shouldn't be a problem. blockProgressionDimension or blockProgressionDirection? Exceptions prove the rule, don't they? :-) They certainly throw it into contrast. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
More style issues
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
Regards
J.Pietschmann
Re: More style issues
Joerg,
thank you for looking into this - fixing typos and style issues in other
peoples code is really quite a gruelling task.
And trying to get agreement on style issues in a community of developers
is virtually impossible, isn't it :-), as we all have our own likes and
dislikes.
On Fri, 9 Sep 2005 07:55 am, J.Pietschmann wrote:
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
+1 I am with you here - allthough I am guilty as well: If I find a class
written in hungarian style and I have to make a modification I will
sick with the style of the original author. What I dislike most is
mixing styles as this make code IMO very difficult to read.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
Doesn't worry me too much although I prefer the style you prefer as
well.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
That's a difficult one - I don't think there is a right or wrong here.
And yes consistency would be great (e.g. all layout manager classes
should be called ...LayoutManager and not some ...LM). I agree that
this is not really a typing issue but it is arguable at what length an
identifier actually gets in the way of readability, e.g. is
'lineStartBorderAndPaddingWidth' preferable to 'lineStartBAP' if that
variable is used a lot in expressions which are then split over multi
lines everywhere this variable is used?
What about a WIKI page listing commonly used abbreviations found in the
code base?
So +1 for consistent class names and +1 for consistent and considered
use of abbreviations but please don't ban them altogether.
Regards
J.Pietschmann
Thanks again for taking this on
Manuel
