6 ms·

Google are very strict about things like code style guides, so things like having incorrect spacing, or ivars that aren’t in alphabetical order, or lines wider

by unwind 14y ago

Google are very strict about things like code style guides, so things like having incorrect spacing, or ivars that aren’t in alphabetical order, or lines wider than 80 chars, will all get picked up. Is the part of instance variables having to be sorted alphabetically really true? I did a quick search but only found the C++ style guide, which says nothing like that. It sounds absurd, instance variables should (imo) be grouped logically, not sorted by their names which are not very relevant when it comes to which belong together.

cryowaffle 14y ago
Did you read the part about how it helps dealloc? I can see how that would be nice, if you don't have too many instance variables then it wouldn't be a big deal.
- unwind 14y ago
  No, I missed that part ... I guess it makes some kind of sense, but it seems weird to assume that all instance variables need deallocation. If I have a buffer, and a length, I'd like to keep them together in the code since they both are part of the same thing. The length, however, is likely some integer type that won't need mentioning when destroying the instance.
  - akmiller 14y ago
    But, if you are forced to name alphabetically you might start naming those related instance variables in a related way (which wouldn't necessarily be bad). For example in your case you might have: myFileBuffer and myFileBufferLength which would hopefully be next to each other, no?
jsnell 14y ago
Can't say whether it's true, but the purported reason was stated in the article (same sorting used for declaration and for deallocation, to make reviewing for memory leaks easier).
- objclxt 14y ago
  That's correct: here's the passage in question from the Google Objective-C style guide: > dealloc should process instance variables in the same order the @interface declares them, so it is easier for a reviewer to verify. One engineers idea of 'logical order' may not be another's, so alphabetical order seems as good a sorting method as any. And since the article itself doesn't link to the style guide, here it is: http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml http://google-styleguide.googlecode.com/svn/trunk/objcguide.... Google keep it regularly updated, so it includes newer developments like ARC and the modern literal syntax.
  - scrumper 14y ago
    The style guide (in that link at least) doesn't actually enforce or even mention alphabetical order for ivars. It seems an unusually proscriptive restriction for what's quite a reasonable style guide. The stated restriction - dealloc in declaration order - makes a lot of sense. (Also, line lengths merely have to 'try' to be less than 80 characters, so there's wiggle room here too.)
    - packetslave 14y ago
      Note that the public style guides aren't always a 1:1 match with the internal ones, usually for legacy reasons or to be more consistent with other internal languages. I don't see anything offhand in the internal ObjC guide about alphabetical order for ivars, so it's possible the OP misunderstood the "dealloc in declaration order" rule. It's also possible his specific project had a convention of sorting them alphabetically.
      - tazzy531 14y ago
        Also different teams have slight variations from the official style guide.
  - blueprint 14y ago
    'Logical' may indeed be an insufficient description given that it lacks any inherent substance (logic can demonstrate something which is true or false). Personally I generally organize by kind: model (including state), and then interface (views, etc), and then controllers (including helpers).
addlepate 14y ago
> instance variables should (imo) be grouped logically, not sorted by their names which are not very relevant when it comes to which belong together I used to think that too, about CSS rules. The problem is that "logical grouping" is subjective and vague, and alphabetizing is not. I list them alphabetically by property name, now.
npsimons 14y ago
It sounds absurd, instance variables should (imo) be grouped logically, not sorted by their names which are not very relevant when it comes to which belong together. Not to mention packing, which if you are compiling with enough warnings turned on, can get annoying. I like to use http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py http://google-styleguide.googlecode.com/svn/trunk/cpplint/cp... on my code, but many of the warnings are more style preferences than anything (like where braces go). Still, I agree with most of their style guidelines, and it's nice having checks for things like unnecessary includes, missing includes and missing idempotency preprocessor guards. Edit: BTW, yes, I'm talking primarily about C++; haven't done enough ObjC to know about packing there, so YMMV. As for dealloc arguments, again, I don't know how it's done in ObjC, but in C++ I think it's irresponsible these days to not be using something like shared_ptr<> if you are dealing with heap, thereby eliding the need to even handle deallocs.
spankalee 14y ago
Alphabetizing, or any canonical ordering, can help minimize merge conflicts. We require it for Java imports and lists all over, so I'm not surprised to see it here. In some projects I've worked on, we allow logical groupings, provided comments that describe what they are, but then require alphabetizing within the groups.

by unwind 14y ago

cryowaffle 14y ago

Did you read the part about how it helps dealloc? I can see how that would be nice, if you don't have too many instance variables then it wouldn't be a big deal.

unwind 14y ago
No, I missed that part ... I guess it makes some kind of sense, but it seems weird to assume that all instance variables need deallocation. If I have a buffer, and a length, I'd like to keep them together in the code since they both are part of the same thing. The length, however, is likely some integer type that won't need mentioning when destroying the instance.
- akmiller 14y ago
  But, if you are forced to name alphabetically you might start naming those related instance variables in a related way (which wouldn't necessarily be bad). For example in your case you might have: myFileBuffer and myFileBufferLength which would hopefully be next to each other, no?

jsnell 14y ago

Can't say whether it's true, but the purported reason was stated in the article (same sorting used for declaration and for deallocation, to make reviewing for memory leaks easier).

objclxt 14y ago
That's correct: here's the passage in question from the Google Objective-C style guide: > dealloc should process instance variables in the same order the @interface declares them, so it is easier for a reviewer to verify. One engineers idea of 'logical order' may not be another's, so alphabetical order seems as good a sorting method as any. And since the article itself doesn't link to the style guide, here it is: http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml http://google-styleguide.googlecode.com/svn/trunk/objcguide.... Google keep it regularly updated, so it includes newer developments like ARC and the modern literal syntax.
- scrumper 14y ago
  The style guide (in that link at least) doesn't actually enforce or even mention alphabetical order for ivars. It seems an unusually proscriptive restriction for what's quite a reasonable style guide. The stated restriction - dealloc in declaration order - makes a lot of sense. (Also, line lengths merely have to 'try' to be less than 80 characters, so there's wiggle room here too.)
  - packetslave 14y ago
    Note that the public style guides aren't always a 1:1 match with the internal ones, usually for legacy reasons or to be more consistent with other internal languages. I don't see anything offhand in the internal ObjC guide about alphabetical order for ivars, so it's possible the OP misunderstood the "dealloc in declaration order" rule. It's also possible his specific project had a convention of sorting them alphabetically.
    - tazzy531 14y ago
      Also different teams have slight variations from the official style guide.
- blueprint 14y ago
  'Logical' may indeed be an insufficient description given that it lacks any inherent substance (logic can demonstrate something which is true or false). Personally I generally organize by kind: model (including state), and then interface (views, etc), and then controllers (including helpers).

addlepate 14y ago

> instance variables should (imo) be grouped logically, not sorted by their names which are not very relevant when it comes to which belong together I used to think that too, about CSS rules. The problem is that "logical grouping" is subjective and vague, and alphabetizing is not. I list them alphabetically by property name, now.

npsimons 14y ago

It sounds absurd, instance variables should (imo) be grouped logically, not sorted by their names which are not very relevant when it comes to which belong together. Not to mention packing, which if you are compiling with enough warnings turned on, can get annoying. I like to use http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py http://google-styleguide.googlecode.com/svn/trunk/cpplint/cp... on my code, but many of the warnings are more style preferences than anything (like where braces go). Still, I agree with most of their style guidelines, and it's nice having checks for things like unnecessary includes, missing includes and missing idempotency preprocessor guards. Edit: BTW, yes, I'm talking primarily about C++; haven't done enough ObjC to know about packing there, so YMMV. As for dealloc arguments, again, I don't know how it's done in ObjC, but in C++ I think it's irresponsible these days to not be using something like shared_ptr<> if you are dealing with heap, thereby eliding the need to even handle deallocs.

spankalee 14y ago

Alphabetizing, or any canonical ordering, can help minimize merge conflicts. We require it for Java imports and lists all over, so I'm not surprised to see it here. In some projects I've worked on, we allow logical groupings, provided comments that describe what they are, but then require alphabetizing within the groups.