Skip to main content
13 events
when toggle format what by license comment
Mar 20, 2018 at 15:35 comment added candied_orange @CharonX Not all function names are commands. Some are events. I've said this already. You can rest assured I'll use better names than foo, bar, and baz. I'll document if you are entitled to expect a post condition. Not if you aren't. When I do it will be coupled to the implementation. Not the name.
Mar 20, 2018 at 15:21 comment added CharonX I suppose we can only agree to disagree here. Though I DO hope you thoroughly document your functions, as with your definition of "function names are commands" self-documenting code rather isn't (Data foo = Bar.getFoo(); /*Might actually return null*/ List baz.add(foo); /*Does not add foos on Tuesdays*/ int size = baz.size(); /*Size returns -1 between midnight and sunrise*/) But then again, with the right mindset you won't be surprised that function don't actually do what their name appears to imply (for others) and everything is fine....
Mar 20, 2018 at 15:08 comment added candied_orange @CharonX If you call add on an object (backed by array or not) that by design might not exist, or, by design doesn't accept additions on Tuesday you can expect it to deal with your add command appropriately. Since this isn't a failure you aren't owed an error. This design free's the client from needing to know about the implementation details. A name is not a post condition.
Mar 20, 2018 at 14:57 comment added CharonX If it is a command you might ignore, then what am I supposed to expect when I call a function? It might do what I ask of it, or it might silently(!) do nothing? Pardon me if I feel somewhat astonished if a add function does not add... You mention the Null Object Pattern - which is an entirely different animal, as a Null Object is used in lieu of an non-existing object (e.g. instead of a nullpointer). Calling add() on a null object does -always, predictably- nothing (instead of having to handle e.g. a nullpointer)
Mar 20, 2018 at 14:33 history edited candied_orange CC BY-SA 3.0
added 259 characters in body
Mar 20, 2018 at 14:23 history edited candied_orange CC BY-SA 3.0
added 259 characters in body
Mar 20, 2018 at 14:16 history edited candied_orange CC BY-SA 3.0
added 259 characters in body
Mar 20, 2018 at 14:10 comment added candied_orange @CharonX It's only counterintuitive if you have the wrong mind set. Imagine you tell me to jump and I ignore you. Does it mean you got the name of the command wrong or does it mean you're not my drill sergeant? Abstraction and polymorphism only work when you stop thinking the name tells the whole story. This might not be how your array behaves but it's how the Null Object Pattern behaves. That doesn't make a name a rough guideline or meaningless. It means names aren't results. The ability to tell me to jump isn't a promise that I will jump.
Mar 20, 2018 at 12:18 comment added CharonX Let us imagine an array with the function add(something). There is no need to tell in the function name that it may resize the array if full. But if it were to (silently!) discard the something instead, if the array is full, using your guidelines that would be ok too - which I think many programmers would find... counterintuitive to say the least.
Mar 20, 2018 at 12:17 comment added CharonX "You have no right to assume that any method named showInterstitialAd() actually does what it says it does" ... So function names are rough guidelines at-best, and entirely meaningless at worst? While it is true that it is impossible to give a complete description of what a function does, the essence of its purpose should be reflected in the function's name.
Mar 20, 2018 at 5:58 history edited candied_orange CC BY-SA 3.0
added 2 characters in body
Mar 20, 2018 at 5:50 history edited candied_orange CC BY-SA 3.0
added 374 characters in body
Mar 20, 2018 at 5:41 history answered candied_orange CC BY-SA 3.0