ipsquiggleIt's interesting: these two function call styles are effectively identical, but for some reason the second one feels almost infinitely more flexible and aesthetic to me:
`inst.MoveTo(x, y)`
`MoveTo(inst, x, y)`
Jakub Neruda@ipsquiggle I prefer subject-verb-object syntax. Reads more like a sentence. One has to do more work to make the second syntax more legible:
MoveEntityToLocation(entity, x, y)
MoveEntityToLocation(entity, x, y)
@jakub_neruda True enough. I think of Smalltalk and its style of naming functions and parameters in an extremely verbal style. Its certainly has its own nice aesthetic.
As I've programmed more though, "grammatical" notions have become much less important to me than things like module design and function expressiveness. I can happily use a Lisp if it makes solving my problem easier.
@ipsquiggle I would argue (in the name of Clean code), that the verbosity has more utility than just being aesthetic.
"Function name shall imply the number and order of parameters". MoveEntityToLocation tells you that the function has two logical parameters - entity and location, in this order. Might sound dumb given how good Intellisense is these days, but then you suddenly need to use a function where multiple parameters have the same type, or Intellisense lags or doesn't show up, or you simply just want to code and not wait for it.
Plus the better name is, the less need to write any kind of documentation for it, something us programmers really fear 😀
@jakub_neruda Oh yeah I totally agree! I'm not arguing against verbosity, just saying that english-like grammar symmetries have become less important to me than being able to write simpler more straightforward procedures.
Helpful verbosity is one reason I like namespaced functions:
`inst.Add(.1, .2, .3)`
At a quick glance, what is inst? But add is a perfectly reasonable method name... But!
`RGB.Add(inst, .1, .2, .3)`
That tells the whole story at once, and is easy to search for!
@ipsquiggle A half decent IDE is able to find you all instances of both approaches.
To be honest, both of your examples feel lacking to me.
a) I would wrap those three parameters into a "color" struct.
inst.Add(color) becomes much more expressive that way.
b) Using "inst" as a name instantly obfuscates the intent. If you call it "color" instead, you no longer need that namespace.
c) In this particular case, I would prefer the following syntax:
color += other_color
But I am unsure how many languages outside C++ allow operator overloading. Good for algebraic objects.