Skip to content
This repository has been archived by the owner. It is now read-only.

Block arguments should always be named. #41

Merged
merged 5 commits into from Feb 22, 2013

Conversation

@jackhl
Copy link
Contributor

commented Feb 21, 2013

Block declaration arguments should always include variable names to follow the Objective-C style of named arguments.

Also what's your stance on typedef'ing blocks? I'm somewhat against it just because you can't easily determine the block arguments by command-clicking on a method or quickly looking at a header file.

README.md Outdated
@@ -82,6 +82,8 @@ if (something == nil) {
* Blocks should have a space between their return type and name.
* Block definitions should omit their return type when possible.
* Block definitions should omit their arguments if they are `void`.
* Block definitions should always include argument names.

This comment has been minimized.

Copy link
@jspahrsummers

jspahrsummers Feb 21, 2013

Contributor

When would a block ever have an unnamed argument? Is this something you've actually seen before?

This comment has been minimized.

Copy link
@jackhl

jackhl Feb 21, 2013

Author Contributor

I'm talking about the possibility of a method signature that looks like this:

- (void)methodThatTakesBlock:(void (^)(NSString *, NSData *, NSError *))block;

It's very frustrating when someone does that for two reasons:

  1. I have no idea what those arguments hold.
  2. When I'm typing the method name xcode autocompletes it and then immediately yells at me about unnamed block arguments.

This comment has been minimized.

Copy link
@jackhl

jackhl Feb 21, 2013

Author Contributor

This actually brings up the point that I don't think you should ever omit an argument's name in a C function. For example, I much prefer

void GHAwesomeFunction(int descriptiveName1, int descriptiveName2, float descriptiveName3);

vs

void GHAwesomeFunction(int, int, float);

If you agree, can I add that rule too?

This comment has been minimized.

Copy link
@jspahrsummers

jspahrsummers Feb 21, 2013

Contributor

Ah, gotcha. How about phrasing it like this, then:

Parameters in block types should be named unless the block is initialized immediately.

This allows uses like:

void (^block)(NSString *) = ^(NSString *name) {
};

… where the purpose of the parameter is obvious from the literal, and doesn't need to be duplicated in the type.

This actually brings up the point that I don't think you should ever omit an argument's name in a C function.

We try to limit our conventions to things that might be contentious or not obvious – i.e., our conventions always start with an implicit "Use common sense." I don't think I've ever seen C declarations without parameter names in reputable code. It shouldn't be necessary to say that it's a bad idea.

This comment has been minimized.

Copy link
@jackhl

jackhl Feb 21, 2013

Author Contributor

🎯 Sounds good. I'll reword it but I think I'm going to use Arguments rather than Parameters since that's what's used in the bullet above and elsewhere (unless you have a different preference).

This comment has been minimized.

Copy link
@jspahrsummers

jspahrsummers Feb 21, 2013

Contributor

The use of the word "parameters" is intentional. Parameters are used in declarators, arguments are used in invocations.

Declarations are also different from definitions.

This comment has been minimized.

Copy link
@jackhl

jackhl Feb 21, 2013

Author Contributor

Thanks for the clarification. For declarations vs definitions, I would say "declared property" because I'm telling the consumer/compiler that the property exists but I would say "class definition" because I'm describing the class. Am I on the right track?

This comment has been minimized.

Copy link
@jspahrsummers

jspahrsummers Feb 21, 2013

Contributor

Roughly, a declaration is an interface while a definition is the implementation.

This declares a constant which will be defined in another module:

extern NSString * const NotificationName;

This defines and initializes the constant:

NSString * const NotificationName = @"NotificationName";

Note that these concepts aren't always mutually exclusive. This both declares and defines a variable i (since the definition marks its first appearance, it also functions as a declaration):

- (void)method {
    int i;
}
README.md Outdated
@@ -82,6 +82,8 @@ if (something == nil) {
* Blocks should have a space between their return type and name.
* Block definitions should omit their return type when possible.
* Block definitions should omit their arguments if they are `void`.
* Block definitions should always include argument names.
* Block definitions should not be `typedef`’d.

This comment has been minimized.

Copy link
@jspahrsummers

jspahrsummers Feb 21, 2013

Contributor

This seems unnecessarily restrictive. We don't typically typedef block types, but there's no reason to elevate that to a rule.

This comment has been minimized.

Copy link
@jackhl

jackhl Feb 21, 2013

Author Contributor

Okay I agree, I'll remove it. I wasn't sure about that one anyway.

@ghost ghost assigned jspahrsummers Feb 21, 2013

@dannygreg

This comment has been minimized.

Copy link

commented Feb 22, 2013

Big 👍 from me to this.

@alanjrogers

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2013

Yeah, definite 👍 from me.

@jspahrsummers

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2013

💎

jspahrsummers added a commit that referenced this pull request Feb 22, 2013

Merge pull request #41 from Jlawr3nc3/block-params
Block arguments should always be named.

@jspahrsummers jspahrsummers merged commit b8b6fac into github:master Feb 22, 2013

@jspahrsummers jspahrsummers removed their assignment May 22, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.