[
https://issues.apache.org/jira/browse/PDFBOX-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378800#comment-14378800
]
John Hewson edited comment on PDFBOX-2576 at 3/24/15 10:33 PM:
---------------------------------------------------------------
They happen not to use instance variables, but pretty much any of those methods
could be altered in the future to make use of instance variables - there's
nothing fundamentally static about those methods, because the don't _need_ to
be static. That stack overflow link is a good example, because obviously there
is mixed advice, but there's a fairly clear message which gets repeated that
static methods are for cases where "the method is needed without an instance of
the class". That's not the case in the code we have, where there are instance
private methods that happen not to use class variables, but easily could do.
My rule of thumb, which I think reflects the general message on stack overflow
is that is a method shouldn't be static unless it _needs_ to be. If you don't
need to calling a method without a class instance, it isn't static, whether or
not it uses class variables is irrelevant, the question is "does it make sense
to call this method without a class instance?" and the answer is usually "no".
Genuinely static code _has_ to be declared static, or it won't compile.
Everything else is non-static. Sorry I didn't notice this earlier, this is
quite a busy JIRA issue and I can't always keep up with it.
was (Author: jahewson):
They happen not to use instance variables, but pretty much any of those methods
could be altered in the future to make use of instance variables - there's
nothing fundamentally static about those methods, because the don't _need_ to
be static. That stack overflow link is a good example, because obviously there
is mixed advice, but there's a fairly clear message which gets repeated that
static methods are for cases where "the method is needed without and instance
of the class". That's not the case in the code we have, where there are
instance private methods that happen not to use class variables, but easily
could do.
My rule of thumb, which I think reflects the general message on stack overflow
is that is a method shouldn't be static unless it _needs_ to be. If you don't
need to calling a method without a class instance, it isn't static, whether or
not it uses class variables is irrelevant, the question is "does it make sense
to call this method without a class instance?" and the answer is usually "no".
Genuinely static code _has_ to be declared static, or it won't compile.
Everything else is non-static.
> Improve code quality
> --------------------
>
> Key: PDFBOX-2576
> URL: https://issues.apache.org/jira/browse/PDFBOX-2576
> Project: PDFBox
> Issue Type: Task
> Affects Versions: 2.0.0
> Reporter: Tilman Hausherr
> Assignee: John Hewson
> Attachments: GraphicsOperatorProcessor.patch,
> SecuryHandlerFactory.patch, org.apache.fontbox.afm.patch,
> org.apache.fontbox.cff.cffparser.patch, org.apache.fontbox.cff.patch,
> org.apache.fontbox.cmap.patch,
> org.apache.pdfbox.contentstream.operator.state.patch,
> org.apache.pdfbox.cos.patch, org.apache.pdfbox.filter-2.patch,
> org.apache.pdfbox.filter.patch, org.apache.pdfbox.pdfwriter.COSWriter.patch,
> org.apache.pdfbox.pdmodel.documentinterchange.logicalstructure.patch,
> org.apache.pdfbox.pdmodel.documentinterchange.patch,
> org.apache.pdfbox.preflight.graphic.patch, pdfbox-override-patch.txt,
> pdfbox-raw-type-patch.txt, pdfcloneutility-patch.txt,
> pdftextstripperbyarea-patch.txt, ttfsubsetter-2.patch, ttfsubsetter-3.patch,
> ttfsubsetter-patch.txt
>
>
> This is a longterm issue for the task to improve code quality, by using the
> [SonarQube
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
> hints in different IDEs, the FindBugs tool and other code quality tools.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
