[xwiki-devs] About the merits of private static functions.
I have found that I like static private functions because they allow me to make promises about my code, making it more self explanatory and I was interested in opinions from others about it. It's not something I would want to force on other people but I would use it myself if people don't think it's too messy. Reasoning: A private method which does not touch any state of the is easy to review, it has no side channels to modify or access information so: #1 with the same inputs it will always give the same output. #2 it will not affect the world around it aside from it's inputs and output (no surprise side effects). By declaring the private method static, you make that promise and the compiler will hold you to it. As a reviewer I can let my guard down when looking at the code because it doesn't affect object state so it can't be the source of some types of bugs. The code is sandboxed so to speak. These assumptions do not hold true if static variables are used but I believe those should never be used unless absolutely necessary and when they are, code should be reviewed more closely anyway. Example: https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-transfo... If I were writing this now, I would be tempted to make these into static functions: private Block convertToDeepTree(Block sourceTree, String iconName) private void mergeTree(Block targetTree, Block sourceTree) private int indexOf(List<Block> targetBlocks, Block block) private boolean blockEquals(Block target, Block source) Anyone have any thoughts on this pattern? Caleb
On Tue, Aug 30, 2011 at 4:35 AM, Caleb James DeLisle <[email protected]> wrote:
I have found that I like static private functions because they allow me to make promises about my code, making it more self explanatory and I was interested in opinions from others about it. It's not something I would want to force on other people but I would use it myself if people don't think it's too messy.
Reasoning: A private method which does not touch any state of the is easy to review, it has no side channels to modify or access information so: #1 with the same inputs it will always give the same output. #2 it will not affect the world around it aside from it's inputs and output (no surprise side effects). By declaring the private method static, you make that promise and the compiler will hold you to it. As a reviewer I can let my guard down when looking at the code because it doesn't affect object state so it can't be the source of some types of bugs. The code is sandboxed so to speak. These assumptions do not hold true if static variables are used but I believe those should never be used unless absolutely necessary and when they are, code should be reviewed more closely anyway.
Example: https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-transfo...
If I were writing this now, I would be tempted to make these into static functions: private Block convertToDeepTree(Block sourceTree, String iconName) private void mergeTree(Block targetTree, Block sourceTree) private int indexOf(List<Block> targetBlocks, Block block)
private boolean blockEquals(Block target, Block source)
Note: The javadoc of this method is wrong since it's only handling SpecialSymbolBlock and WordBlock according to the code. If any code really expect what the javadoc is saying it will have some surprises... Now if I really needed to do this I would probably put something in Block itself I think since it's generic enough and that's anyway the only way to do it properly since otherwise you need a lots of crappy if/else as you can see.
Anyone have any thoughts on this pattern?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Aug 30, 2011 at 4:35 AM, Caleb James DeLisle <[email protected]> wrote:
I have found that I like static private functions because they allow me to make promises about my code, making it more self explanatory and I was interested in opinions from others about it. It's not something I would want to force on other people but I would use it myself if people don't think it's too messy.
Reasoning: A private method which does not touch any state of the is easy to review, it has no side channels to modify or access information so: #1 with the same inputs it will always give the same output. #2 it will not affect the world around it aside from it's inputs and output (no surprise side effects). By declaring the private method static, you make that promise and the compiler will hold you to it. As a reviewer I can let my guard down when looking at the code because it doesn't affect object state so it can't be the source of some types of bugs. The code is sandboxed so to speak. These assumptions do not hold true if static variables are used but I believe those should never be used unless absolutely necessary and when they are, code should be reviewed more closely anyway.
Example: https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-transfo...
If I were writing this now, I would be tempted to make these into static functions: private Block convertToDeepTree(Block sourceTree, String iconName) private void mergeTree(Block targetTree, Block sourceTree) private int indexOf(List<Block> targetBlocks, Block block) private boolean blockEquals(Block target, Block source)
Anyone have any thoughts on this pattern?
Private static methods without side effects... looks like you're promoting a kind of functional programming style :) Which is good imho. -Fabio
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Caleb James DeLisle -
Fabio Mancinelli -
Thomas Mortagne