[ 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:35 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 a method shouldn't be static unless it _needs_ to be. If you don't need to call 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 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. > 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