q1.text

Tracks is both a noun and verb, so first is ambiguous. Third looks less aesthetically pleasing with the ugly With.
2/11/2016 2:52 PM
short and clear
2/11/2016 2:45 PM
concise but doesn't lose meaning
2/11/2016 2:39 PM
with helps readability, but putting a split between with/mediaType sounds unnatural
2/11/2016 2:19 PM
Prefer 3rd, reads better. But find myself always writing 1st.
2/11/2016 2:17 PM
The 'with' doesn't add enough meaningful information to justify the noise
2/11/2016 2:08 PM
Concise without meaning obscured
2/11/2016 2:02 PM
because "with" applies to both args (otherwise 2nd option)
2/11/2016 1:52 PM
With is implied
2/11/2016 1:44 PM
Shorter
2/11/2016 1:44 PM
everything has a unified style, the first style is awful and the second weird
2/11/2016 1:40 PM
clear method name, you understand what it does
2/11/2016 1:35 PM
Works well with default arguments
2/11/2016 1:22 PM
you are retrieving tracks matching a set of parameters
2/11/2016 1:18 PM
Without the with it was not clear to me that this was a method that searched for matches. I slightly prefer form c over b because the with applies to both parameters
2/11/2016 1:14 PM
Name of method is clearer on its own (else "tracks" could be interpreted as a verb), makes "clean" parameter names without having to use external labels
2/11/2016 1:11 PM
Warning 'tracks' could also be a verb (a is tracking what now?). I found this confusing
2/11/2016 1:06 PM
(These long answers, often complaining about names with prepositions, are Fritz Anderson.) They don't mean the same. Is the return value a collection of media tracks, or are we asking if a is tracking in parallel to something? If the former, it should be "_of_MediaType:" (underscores for emphasis only). Substitute "of" for "with" in the other examples to see why you shouldn't factor the preposition into the func name.
2/11/2016 1:01 PM
Hard to tell your intent without a return type, but this feels like you're filtering a Set, and "with" definitely would imply that - and belongs in the function name ... a.tracksWith(composer: c, albumType: x) feels right too
2/11/2016 1:01 PM
more concise and still clear
2/11/2016 1:00 PM
Short Funktion Name
2/11/2016 12:54 PM
This one's a toughie because "tracks" can be either a verb or noun, but at least it names both arguments in the same fashion.
2/11/2016 12:48 PM
You may want to specify a different tracksWith function such as tracksWith(tag:
2/11/2016 12:35 PM
I have a java background and this is more familiar.
2/11/2016 12:33 PM
The first one reads like a slice into a 2-D query space.
2/11/2016 12:30 PM
The 2nd option seems strange to have one parameter using with and one not. In the third option, the with seems redundant
2/11/2016 12:28 PM
When I first started working in Swift I wrote like the second one because of ObjC, but now I prefer the first form.
2/11/2016 12:26 PM
The method name tells you what you're getting back (or what you, the caller, wants from `a`, depending on how you think about it), the argument labels tell the method how you want the thing(s) you're getting back, and the preposition makes the whole thing read well.
2/11/2016 12:23 PM
I don't really like any, none actually say what they will do, tracksWith is closest to what it should be: filterTracksBy, if such a method should even exist. 'tracks' sounds like a property and parameterized access seems like an antipattern, should be used more like a.tracks.filter(...).soOn().andSoForth()
2/11/2016 12:21 PM
Less noise
2/11/2016 12:18 PM
The 'width' doesn't add clarity to the interface
2/11/2016 12:11 PM
The function (apparently) returns a set of "tracks with" a set of criteria. The second option is ok, too, but forced to choose one I think the last is more clear.
2/11/2016 12:06 PM
Order shouldn't matter. This would be still better "withMediaType:, withComposer:"
2/11/2016 11:55 AM
I prefer shorter names and don't think the preposition adds any value.
2/11/2016 11:52 AM
The preposition steers my mind off from thinking of 'tracks' as a verb. Alternatively, 'findTracks' or 'listTracks' would work without any preposition.
2/11/2016 11:50 AM
a.tracksWithMediaType(b... is be my preference.
2/11/2016 11:44 AM
I see this clearer when Xcode autocompletes
2/11/2016 11:43 AM
I'd prefer something like "tracksMatchingQuery(...)"
2/11/2016 11:43 AM
the parens act as a de-facto "with". a.tracks() still makes sense, and you don't have ivars with crappy names like "withSomething"
2/11/2016 11:34 AM
because the variable name 'mediaType' would make more sense in the function that follows
2/11/2016 11:33 AM
no reason to be verbose...
2/11/2016 11:31 AM
It's code. Not English. Mediatype and composer logically linked as track metadata. Method name needs to be more informative and less fussy about English grammar. Is it searching for tracks in a DB? Setting metadata on a subset of tracks?
2/11/2016 11:30 AM
This is really a named subscript in disguise. Read the parentheses as square brackets.
2/11/2016 11:26 AM
None of the above really. I would perfer: a.filterTracks(mediaType: b, composer: c). Just "tracks" is too ambiguous so it leads to answer C for more context, but I don't like the preposition in the name...
2/11/2016 11:24 AM
Tribal knowledge conditioning with Cocoa makes me presume the 'with'. Wouldn't work for folks new to Cocoa though
2/11/2016 11:24 AM
It flows best. Personally, I would use tracksWithMediaType(b, composer: c)
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
tracksWith would support multiple signatures
2/11/2016 11:12 AM
clearer
2/11/2016 11:05 AM

q2.text

Last option is ambiguous (who's encoding who?). Selected option is otherwise most concise.
2/11/2016 2:52 PM
encode(coder: b) is also fine
2/11/2016 2:46 PM
concise but doesn't lose meaning
2/11/2016 2:39 PM
same as above
2/11/2016 2:19 PM
Si,liar to 1, but the label-less one could be misleading. "Should a encode b?"
2/11/2016 2:08 PM
As above but "withCoder" would also be ok due to the verb usage
2/11/2016 2:02 PM
I prefer a.encode(with: b) // Need "with" to clarify I'm not encoding "b" but the rest is obvious without the word Coder (I beieve my preference actually aligns with Dave's latest take)
2/11/2016 1:52 PM
With is implied and coder is explicit
2/11/2016 1:44 PM
With is implied
2/11/2016 1:44 PM
same as above, uniform style
2/11/2016 1:40 PM
clear method name, one argument, no label, like in all languages
2/11/2016 1:35 PM
Not sure
2/11/2016 1:22 PM
Encode is the function, withCoder === using coder, different than previous one which was a filter
2/11/2016 1:18 PM
Coder doesn't seem to add any info
2/11/2016 1:14 PM
The important information is the fact that we're encoding. The fact that we need a coder to do it is secondary.
2/11/2016 1:11 PM
Whatever is passed will help with the 'encoding' task
2/11/2016 1:06 PM
I. Precedent. II. Good precedent, because the functionality is unique to a protocol, and should have a unique name. III. Does not imply that the func is overloaded or takes an indefinite (e.g. AnyObject) argument.
2/11/2016 1:01 PM
Encode is the verb, coder is just a mechanism, you could have a.encode(somethingElse: b) in theory later down the line
2/11/2016 1:01 PM
without a label we might think b is being encoded
2/11/2016 1:00 PM
The Long Name with only one Attribute is the Clearest
2/11/2016 12:54 PM
More "Swifty". Putting "with" in the argument name seems wrong to me.
2/11/2016 12:48 PM
Same reason as above
2/11/2016 12:35 PM
Descriptive function names FTW
2/11/2016 12:33 PM
The label is important because b is not the object to encode.
2/11/2016 12:30 PM
Even though this contraticts what I say in my comments for question 9, the first form just feels better.
2/11/2016 12:26 PM
Like 1., except the method name tells you what you'd like `a` to do.
2/11/2016 12:23 PM
a.encode(...) implies acting on something in the parameter set by a, though I think based on the choices what is being done is an action on a with parameterization of its behavior, so a.encodeWith(...) better communicates that.
2/11/2016 12:21 PM
Less noise
2/11/2016 12:18 PM
right amount of clarity
2/11/2016 12:11 PM
May be the old Objective-C-ist in me, but if there's only one argument I feel like it reads better to keep as much of it together as possible.
2/11/2016 12:06 PM
While I prefer shorter names, I prefer the arguments to be named for clarity
2/11/2016 11:52 AM
Why not? Not `a.encode(b)` because it's actually `a` that gets encoded. Consistent with the previous naming. Also easy to colloquially refer to as 'encodeWith' (without mentioning the label). If someone considered giving a default value to the 'coder' parameter, I'd suggest adding another parameterless `encode()` method instead.
2/11/2016 11:50 AM
"coder" makes clear that this role isn't fulfilled by a
2/11/2016 11:43 AM
the parens act as a de-facto "with". a.tracks() still makes sense, and you don't have ivars with crappy names like "withSomething"
2/11/2016 11:34 AM
same as #1
2/11/2016 11:33 AM
every programmer with experience of a language...
2/11/2016 11:31 AM
Again, code.
2/11/2016 11:30 AM
When an explicit preposition is not used, "with" is implied. See initializers for evidence.
2/11/2016 11:26 AM
The preposition is already implicit because the "(".
2/11/2016 11:24 AM
Let type inference thrive! If I don't know the type of b, I'm only a command click away from learning. Reasoning only applies to single parameter functions though...
2/11/2016 11:24 AM
Most descriptive and flows naturally
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
encodeWith would support multiple signatures
2/11/2016 11:12 AM

q3.text

First is acceptable but last edges it out thanks to concision. Second option is awful.
2/11/2016 2:52 PM
B and c have a stronger relationship than function verb + b, excluding c, but I'd also accept moveFrom()
2/11/2016 2:46 PM
b is the "from", c is the "to", together you get a movement
2/11/2016 2:39 PM
natural pairing between the arguments, but the second option wouldn't be too much of a problem
2/11/2016 2:19 PM
Tough call. Interpreting it as movement from point to point, first seems the neatest. If moving a something to a place, I'd vote third.
2/11/2016 2:08 PM
Both should be labelled as not moving 'b'
2/11/2016 2:02 PM
the two arguments are of equal importance to the semantics, this option is the only one that treats them the same.
2/11/2016 1:52 PM
From is implied in the name but helpful in the arguments
2/11/2016 1:44 PM
The function name should make sense by itself
2/11/2016 1:44 PM
intent is clear, last one is also good if it actually moves b to c xD
2/11/2016 1:40 PM
easiest to read; from method moveFrom i'd expect 1 argument...
2/11/2016 1:35 PM
b and c play a different role
2/11/2016 1:18 PM
Makes most clear which is source and dest
2/11/2016 1:14 PM
Clean method name. Each parameter is labeled clearly at the call site.
2/11/2016 1:11 PM
See above for not ending func names with prepositions. The third doesn't mean the same thing as the others: It says "hey `a`, move a `b` to somewhere". The other two say "move a from one place to another." (Then why the "from?" `a` is in only one place, right?)
2/11/2016 1:01 PM
Cleanest and simplest
2/11/2016 1:01 PM
we are moving b, so no need for a label
2/11/2016 1:00 PM
Again more than one Attribute i like the Short Function Name and Details in the Attributes
2/11/2016 12:54 PM
It matches the way I think about this method.
2/11/2016 12:48 PM
I prefer the explicitness
2/11/2016 12:35 PM
Again descriptive naming is descriptive.
2/11/2016 12:33 PM
I presume this is a line-drawing method which takes two endpoints.
2/11/2016 12:30 PM
feels more explicit, and a little strange to put it in the method name...
2/11/2016 12:26 PM
Same as 2.
2/11/2016 12:23 PM
Method should say what the action is, all parameters should be labeled, the label should not be tacked onto the method. That was the worst part of Obj-C naming conventions.
2/11/2016 12:21 PM
Has more symmetry
2/11/2016 12:18 PM
clarity
2/11/2016 12:11 PM
If there are more than one argument, my gut feeling is that they should all be labeled. There may be (probably are) exceptions, but this one feels pretty clear to me.
2/11/2016 12:06 PM
As per 2.
2/11/2016 11:52 AM
In the previous cases, you could say the preposition affected all parameters, or at least tere was no contender. In this case, 'from' and 'to' clearly are peers to each other, so I'd move them inside the parens. Also, moving (aside from moving in place, and arguably even) there is no other moving but from someplace to someplace.
2/11/2016 11:50 AM
All are to vague -> a.move$Type(source: a, destination: c)
2/11/2016 11:43 AM
it's clean, and it works fine in English... b is the direct object, and the parens effectively indicate the implied preposition
2/11/2016 11:34 AM
beyond Objective-C has run across this type...
2/11/2016 11:31 AM
From and to are logically connected and (hypothetically) could even be reversed.
2/11/2016 11:30 AM
These parameters are complete prepositional phrases, as is the standard, when parentheses don't mean "with".
2/11/2016 11:26 AM
The action is move, the arguments simply dictate how that should happen.
2/11/2016 11:24 AM
In this case, the argument labels make my geometric intentions less ambiguous
2/11/2016 11:24 AM
That's how I've always named methods
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
I don't want the first label every dropped.
2/11/2016 11:12 AM

q4.text

Probably because I'm very used to objc
2/11/2016 2:52 PM
LoadValues(keys:[]) seems contradictory to me, like the parameter should be values. I would add the extra stuff, just so it reads clearly.
2/11/2016 2:46 PM
not sure. Don't like the argument labels in this one
2/11/2016 2:39 PM
keeping the preposition with its object sounds more seems like the best place to put the split
2/11/2016 2:19 PM
Concise, no need for superfluous 'for'
2/11/2016 2:02 PM
Any of them but the last option. Guiding principle is base name should be what you are doing and argument labels for how you are doing it (and I can see an argument for the intent of this method to be loading "values" or "valuesForKeys"). I'm also for removing prepositions that don't change the semantic meaning, but not enough to warrant special guidelines to make that change.
2/11/2016 1:52 PM
The sentence seems right here
2/11/2016 1:44 PM
whatever you call it the with, forKeys etc should not be included in the parameter name
2/11/2016 1:40 PM
clear method name, one argument, no label, like in all languages
2/11/2016 1:35 PM
Action is LoadValues matching keys
2/11/2016 1:18 PM
I'd actually drop keys entitrely
2/11/2016 1:14 PM
Cleaner IF there are other overloads with something else than "keys". Else I would prefer the first option.
2/11/2016 1:11 PM
I. Again, no prepositions ending func names. II. Omitting the preposition breaks the phrasiness of the API.
2/11/2016 1:01 PM
Again, you could have a.loadValues(somethingElse: ...) so this feels the right one.
2/11/2016 1:01 PM
`for` feels redundant. it doesn't make it clearer than it is
2/11/2016 1:00 PM
Good balance of grammatical sense yet still seeming to be Swift-like.
2/11/2016 12:48 PM
For obvious function names, I'm okay with putting the value name inside the parens.
2/11/2016 12:33 PM
The general operation is "loading values".
2/11/2016 12:30 PM
See comment on question 9, but substitute "for..." with "with..."
2/11/2016 12:26 PM
"Values" belongs in the method name, as, like the previous questions, it tells you what the 'action' is; what you would like `a` to do. The argument labels (with prepositions), gives `a` (and the reader) the supplementary information it needs in order to complete the action.
2/11/2016 12:23 PM
method says what it's doing, could be a version without parameters for all values, all parameters are labeled, and forKeys reads more naturally that just keys.
2/11/2016 12:21 PM
Similar to #2 - only one argument, keep as much of the "wordiness" together as possible.
2/11/2016 12:06 PM
As per 1.
2/11/2016 11:52 AM
I don't have a good reason here.
2/11/2016 11:50 AM
I expect there are other ways to specify what to load
2/11/2016 11:43 AM
short, clear, parens act as delimiter
2/11/2016 11:34 AM
of syntax, so why would anyone wish to *force*...
2/11/2016 11:31 AM
"for" is important here - it clarifies that the keys are the source, not the destination for the "values". It's a familiar usage for long-term Cocoa programmer also.
2/11/2016 11:30 AM
It's closest to what it should be: a.values[b, c, d]
2/11/2016 11:26 AM
Again, the preposition is simply useless words.
2/11/2016 11:24 AM
This one is tough. The values only make sense in context with their keys, so I think you need both 'values' and 'keys' written out. Keys is definitely part of the parameter name, so I like just shoving them together.
2/11/2016 11:24 AM
Same as 2
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
I think loadValues is clear and could support multiple argument signatures
2/11/2016 11:12 AM

q5.text

I've recently written a similar one "a.respond(with: b)", which I think reads more nicely, but I think fourth might be clearer on call site. On the hand, b should be well typed, providing enough information to afford the nicety
2/11/2016 2:08 PM
In this case 'with' clarifies intent
2/11/2016 2:02 PM
actually prefer a.respond(b) since "with" seems vacuous (but if it wasn't a.respond(with: b)
2/11/2016 1:52 PM
another option would be a.respondWith(data: b)
2/11/2016 1:40 PM
clear method name
2/11/2016 1:35 PM
action is respond, parameter is data
2/11/2016 1:18 PM
Data is a meaningless term that adds no value
2/11/2016 1:14 PM
"With" is redundant in this case.
2/11/2016 1:11 PM
whatever is passed to 'a', it will help it WITH 'responding
2/11/2016 1:06 PM
Harder. I. My rule of no prepositions in the func name. II. SOMETHING should explain what the nature of the response is (it’s some kind of NSData representation). III. If the API has a general concept of response, then the mode of response should be factored into the parameter name, so answer 2; if response-with-data is a unique concept, then 3. 4 is open to “Hey a, respond, given this data in b.”
2/11/2016 1:01 PM
Maybe just a.respond(b), or probably a.sendResponse(b)
2/11/2016 1:01 PM
`with`, `for` and other prepositions should only used when something is ambiguous
2/11/2016 1:00 PM
Too little information in the short name "data".
2/11/2016 12:48 PM
None, really. respond is too vague
2/11/2016 12:33 PM
As with a.encode, the argument is not the direct object.
2/11/2016 12:30 PM
See comment on question 9.
2/11/2016 12:26 PM
Same reasons as above.
2/11/2016 12:23 PM
Again, method name explains the intent, parameters are all labeled, and there could be overloads of respond that take different types with different label names, and withData reads more naturally than just data
2/11/2016 12:21 PM
Same as for #s 1 and 4. As for why keep the word "data," I disagree strongly with the notion that we do not need to include type information in names just because the language is strongly typed. Just because the compiler knows with certainty what type something is doesn't mean the maintenance programmer who has to figure the code out months or years later knows.
2/11/2016 12:06 PM
As per 1 & 2.
2/11/2016 11:52 AM
Terse, but makes it clear that `b` ought to be treated as bytes, and not, say, formatted as JSON.
2/11/2016 11:50 AM
Assuming there are other respond methods (String, file...)
2/11/2016 11:43 AM
a more verbose style unless it's a preference?
2/11/2016 11:31 AM
"with" helps clarify that the data is part of the response. But the method name (not the signature) shouldn't end with a dangling preposition.
2/11/2016 11:30 AM
Same answer as 2.
2/11/2016 11:26 AM
"respond" is too little context I think, but again, the prepositions don't add meaning. "sendReponse(data: b)" seems better.
2/11/2016 11:24 AM
Same Type inference reasoning as earlier. 'With' is very different than 'to' so I think it makes sense as part of the function name
2/11/2016 11:24 AM
Same as 2
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
ugh, not really liking any of these, want a.respondWith(data: b)
2/11/2016 11:12 AM

q6.text

I would actually most prefer `accountType(typeIdentifier: a)` so I chose the nearest option that lacked an ugly "with".
2/11/2016 2:52 PM
None in reality, I prefer accountType(identifier: a)
2/11/2016 2:49 PM
I can see having this overloaded, with different identifiers.
2/11/2016 2:46 PM
accountType(identifier: a) maybe better
2/11/2016 2:39 PM
Least verbose with no loss of clarity and easier to parse
2/11/2016 2:02 PM
primary semantic intent is to get the account type
2/11/2016 1:52 PM
None of the Above actually, accountType(identifier: a)
2/11/2016 1:44 PM
accountTypeWith(accountTypeIdentifier: a)
2/11/2016 1:40 PM
clear method name, one argument, no label, like in all languages
2/11/2016 1:35 PM
With is relevant because this feels like a factory method. Omitting the "with" might be confusing.
2/11/2016 1:11 PM
Why repeat "account" and "type"? 'accountType(identifier:a)'
2/11/2016 1:06 PM
None of the above. I. The context is "account;" we can do the math about the identifier being for an account. II. The context is an account _type._ We can do the math about that what’s being identified. “Do the math” elision is at the core of naked-dot references to enum cases, so it’s in the spirit of the language. III. No prepositions in func names. IV. Grammatical phrasing. V. Therefore accountType(withIdentifier identifier:) or …forIdentifier:. account and type aren't repeated.
2/11/2016 1:01 PM
Context would be clearer, but this feels like a pure function that does one thing
2/11/2016 1:01 PM
would even trim it to `accountType(identifier: a)`
2/11/2016 1:00 PM
More "Swifty"
2/11/2016 12:48 PM
Java.
2/11/2016 12:33 PM
I don't really like any of these; not sure what the function does (is it a constructor or a query?)
2/11/2016 12:30 PM
See comment on question 9.
2/11/2016 12:26 PM
In addition to the same reasons as above, the extra "Account" in the argument label clarifies what kind of "type identifier" the method is asking for (is it an `AccountType`, UTI, etc.).
2/11/2016 12:23 PM
Making many assumptions on this one. Assuming purpose is to transform from AccountTypeIdentifier, which could be its own type or just a primitive with expected values into AccountType concrete value/object. Given that, prefer that the intent is specified in the function name and parameters control and indicate type compatibility where this could potentially expand in future overloads or with further optional transformation parameterization
2/11/2016 12:21 PM
would prefer accountType(identifier: a)
2/11/2016 12:11 PM
None of the above. Best would be: accountTypeWithTypeIdentifier(a)
2/11/2016 12:06 PM
As per 1.
2/11/2016 11:52 AM
I suspect this is a factory method and not a search to a varying set of available account types. In the latter case, I'd probably append a preposition to the basename or prepend a verb.
2/11/2016 11:50 AM
Actually: accountType(identifier: a)
2/11/2016 11:49 AM
To many words in the first choice
2/11/2016 11:43 AM
better IMO is `accountType(identifier: a)`
2/11/2016 11:34 AM
Here, "with" seems redundant- what clarity does it add?
2/11/2016 11:30 AM
Closest to what it should be: AccountType(identifier: a) or accountTypes[identifier: a]
2/11/2016 11:26 AM
Prepositions dont' really add anything for me.
2/11/2016 11:24 AM
Pure verbosity, this one just rolls off the tongue better
2/11/2016 11:24 AM
Actually I prefer accountType(withIdentifier: a)
2/11/2016 11:21 AM
Same as 2
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
none, want accountTypeWith(identifier:a)
2/11/2016 11:12 AM

q7.text

Again, noun/verb ambiguity makes me antsy, and the second is more concise than the first.
2/11/2016 2:52 PM
Would have to know more to have a strong opinion. type(property:) might also work for me. Or even just type(x)
2/11/2016 2:46 PM
would prefer typeOfProperty(a)
2/11/2016 2:39 PM
Either typeOf(property: a) or type(property: a)
2/11/2016 2:20 PM
Or "type(of: a)"
2/11/2016 2:08 PM
Of property isn't to bad either
2/11/2016 2:02 PM
typeOfProperty(a) // I know this doesn't fit the pattern of where I put the prepositions in the above examples, but "type of property" feels like the primary semantics.
2/11/2016 1:52 PM
uniformity
2/11/2016 1:40 PM
none of the above honestly - label is unnecessary
2/11/2016 1:35 PM
Nicer IF overloads allow getting the type of other things
2/11/2016 1:11 PM
What exactly is returned here? Unclear! 'Type' as in value type?
2/11/2016 1:06 PM
I. No prepositions at the _end_ of func names. II. Is there a general concept of `type`, of which going through a `property` is an overloaded instance? Then `type(ofProperty property:)`. III: Is the primary concept a `property` that may be of one type or another? Then `typeOfProperty(a)`, or better, `a.type`.
2/11/2016 1:01 PM
typeOf(a) seems better
2/11/2016 1:01 PM
just `type` is ambiguous, `of` adds value here
2/11/2016 1:00 PM
Too little information in the short name "type". Almost looks like a usr-define data type being created.
2/11/2016 12:48 PM
Java.
2/11/2016 12:33 PM
I prefer a.type to all of these.
2/11/2016 12:30 PM
while more verbose, this tells me what i'm going to get and what the method needs to get that in the clearest way.
2/11/2016 12:26 PM
To expand slightly on previous comments: the method name should completely describe what it does or what it returns. Neither `typeOf` or `type` do this. Even though `property` is used in the argument label (this may be a case where it can be omitted), without "Property" in the method name, it is not clear what the method is going to do.
2/11/2016 12:23 PM
Not really a fan of this as a standalone function at all, and have to make an exception to the usual due to 'type' not saying enough and 'typeOfProperty' being too specific. But honestly think such a function should be a universally available property of a given entity's metadata.
2/11/2016 12:21 PM
Again, none of the above. Should be: typeOfProperty(a)
2/11/2016 12:06 PM
As per 2.
2/11/2016 11:52 AM
I'm unsure because I don't understand the context well enough. Rhymes with sizeof.
2/11/2016 11:50 AM
a.propertyType?
2/11/2016 11:43 AM
I would have actually preferred typeOfProperty(a)
2/11/2016 11:32 AM
Relatively clear method name, especially when compared with terseness of alternatives.
2/11/2016 11:30 AM
Closest to what it should be: type(of property: a) or a.type
2/11/2016 11:26 AM
Probably because I'm so used to the "typeof" keyword. But really, I don't have enough context for any of them to be considered good.
2/11/2016 11:24 AM
'Of' means something more here than in many cases, and therefore belongs with the function name
2/11/2016 11:24 AM
I would actually prefer typeOfProperty(a)
2/11/2016 11:20 AM
Concise, follows Swift style
2/11/2016 11:18 AM
I'm trying to be consistent here
2/11/2016 11:12 AM

q8.text

Sounds more like a sentence, the With isn't part of the pre-parenthesis name which is where it looks the worst.
2/11/2016 2:52 PM
I don't really like any of these. But the last one seems most informative of what is returned (the others suggest Boolean or ranking or something)
2/11/2016 2:46 PM
comparePositionInDecodeOrder(cursorPosition: a)
2/11/2016 2:20 PM
Easiest to read
2/11/2016 2:02 PM
comparePositionInDecodeOrder(withPositionOf: a)
2/11/2016 1:52 PM
uniformity, intent
2/11/2016 1:40 PM
easiest to read, but all of those are too long
2/11/2016 1:35 PM
Order of operations / return semantics are clearer
2/11/2016 1:11 PM
conflicted between #1 & 4. But without the word 'with'. comparisons are binary operations after all.
2/11/2016 1:06 PM
VERY CONFUSED. Apparently something has a position in the decode order (or is it a position, expressed in the order of a decoding?) There's no receiver; is this position a global, or is the receiver elided because we're in its context? The verb is compare, it has to start the name. By the precedent of Cocoa comparisons, there’s no `with`, but in any event No Prepositions At End Of Func Names: self.position.compare(cursorPosition position:, options: CursorOptionSet=default), of which the default options may include that the comparison order is "decoding." (or _ cursorPosition:).
2/11/2016 1:01 PM
Clear it returns the positiojn
2/11/2016 1:01 PM
All are too Long
2/11/2016 12:54 PM
"Compare" is necessary, which eliminates choice 6. The "with" shouldn't be in the argument name.
2/11/2016 12:48 PM
Java.
2/11/2016 12:33 PM
I don't know what any of these are doing.
2/11/2016 12:30 PM
Actually I think I like that second one, but with "positionOfCursor" as the parameter name.
2/11/2016 12:26 PM
(Assuming the chosen method returns a comparison result) All of the other methods sound like 'please do this' methods, instead of 'please can I have this' methods. Like previous comments, the method name clearly describes what you are going to get back.
2/11/2016 12:23 PM
Not sure I like any, tbh. Not certain of intent of function but seems like the order should be a parameter. Maybe with more knowledge of what this does, that makes less sense. Either way, no need for PositionOfCursor, just unnecessarily decorative English there. Cursor as an adjective of position is quite fine.
2/11/2016 12:21 PM
It all sounds so very specific it could as well be the first option. Reading these names made me feel ill a bit.
2/11/2016 11:50 AM
these are all terrible
2/11/2016 11:34 AM
None of these make me happy
2/11/2016 11:33 AM
These are all terrible
2/11/2016 11:32 AM
None. How about compareDecodePosition(cursorPosition: a)
2/11/2016 11:31 AM
Shortest unambiguous method name, "with" in label adds marginal clarity.
2/11/2016 11:30 AM
I don't know what this actually is, but the alternatives look more antiquated.
2/11/2016 11:26 AM
Because I think method groups are valuable and this method looks like it could have multiple versions.
2/11/2016 11:24 AM
Still reads like a sentence, but the parameter name captures only what you're passing in, not the context it's being compared to
2/11/2016 11:24 AM
Depents in the inpu type. Is it a cursorPosition or a cursor
2/11/2016 11:21 AM
See 2
2/11/2016 11:20 AM

q9.text

I dislike all of them. Selected is least bad.
2/11/2016 2:52 PM
for seems like the correct preposition here
2/11/2016 2:19 PM
With or for is acceptable here due to the verb
2/11/2016 2:02 PM
exportPresets(compatibleWithAsset: a)
2/11/2016 1:52 PM
If the function name reads as a sentence the parameters name should continue the flow
2/11/2016 1:44 PM
intent
2/11/2016 1:40 PM
none of the above although I'd prefer exportCompatiblePresetsForAsset(a)
2/11/2016 1:35 PM
With is redundant
2/11/2016 1:11 PM
Do these have different meanings? I assume `export` is a verb, not adjectival for export-related presets or presets that are export-compatible. So there is the generic concept of "export," with the special case of narrowing the exported data to those compatible with some kind of asset. exportPresets(compatibleWith asset:) or (compatibleWithAsset asset:) (if the presets might usefully be compatible with some other kind of object). I’m tempted to break No Func Names Ending With Prepositions and accept #1.
2/11/2016 1:01 PM
"for Asset" reads right
2/11/2016 1:01 PM
I'm torn between choice 1 and 3, but 1 is more consistent with my other choices.
2/11/2016 12:48 PM
I don't know. They all make me a little uncomfortable.
2/11/2016 12:33 PM
I don't know what any of these are doing.
2/11/2016 12:30 PM
As with most of these, I like the less ObjC "with..." style, but it's kind of intangible.
2/11/2016 12:26 PM
Same reasons as above. Picked choice over `exportPresetsCompatible(withAsset: a)` because `exportPresetsCompatible` does not make sense on its own (without including the argument label). Whereas, `exportCompatiblePresets` makes perfect sense.
2/11/2016 12:23 PM
This, or, exportPresets(compatibleWithAsset: a) might be better. "What are you doing?" "Exporting presets" "What do you need to know to decide which presets?" "Maybe nothing. Maybe which asset they are compatible with." etc., etc. method name = action performed, the rest should be in parameters to represent required information for the task.
2/11/2016 12:21 PM
exportPresetsCompatibleWithAsset(a)
2/11/2016 12:06 PM
exportCompatiblePresets(a), asset is probably already in the type
2/11/2016 11:49 AM
See 1.
2/11/2016 11:44 AM
Again, would have preferred exportCompatiblePresetsForAsset(a)
2/11/2016 11:32 AM
When comparing use of "with" and "for", I generally find "for" alternatives easier to grok.
2/11/2016 11:30 AM
Closest to what it should be: exportPresets(compatibleWith asset: a)
2/11/2016 11:26 AM
Method group and prepositions are already implied.
2/11/2016 11:24 AM
'With' feels like two things are being delivered and reeks of side effects. 'For' makes me think something will be transformed and then returned
2/11/2016 11:24 AM
I prefer exportPresets(compatibleWith: a)
2/11/2016 11:21 AM
Prefer "asset" outside the parentheses
2/11/2016 11:20 AM
I'm trying to be consistent here
2/11/2016 11:12 AM