Objective-C's tendency to long names (variables, selectors, classes) makes it more "self-documenting" than any language I've worked with. Besides, it's not that bad with autocomplete.
>> I'm not an Objective-C native, but every time I write Objective-C it feels like I'm writing a short story.
That's the whole point of it ;-). Remember you usually only have to write the code once, but you or someone else may have to read it many times.
I used to hate long variable and function names in the past, and I used to hate named parameters. Going on the assumption the time spent typing the code was somehow relevant, and also feeling a little more badass being able to write all this cryptic gibberish to 'control the computer'. In time, I've learned none of this matters and readability of your code is one of the most important quality metrics of any piece of software that needs to be maintained by multiple people and/or over a long timespan.
With Xcode it's just as bad as it looks. If you have multiple names with the same prefix you have to type it all or scroll in a list to select the correct item.
It even fails to complete types like NSString correctly when part of a method call. Not always of course, just when it gets confused, and then I have to delete and type again because the case is wrong.
Now if only that autocomplete would passively infer the current project prefix + (super)class name, so you wouldn't have to type it when it's "local"...
Right, if only it used C#! Then it could use nice short names like ListViewVirtualItemsSelectionRangeChangedEventHandler or DataGridViewColumnDividerDoubleClickEventArgs.
Oh god. That's an artifact of the idiotic VB-style, non-generic event handling "pattern". If event handlers used normal functions like everything else this just wouldn't be a problem (those types just wouldn't exist).
> Asterisks indicating pointers belong with the variable, i.e. NSString text not NSString text or NSString * text, except in the case of global string constants.
I know I have it wrong, but I always feel that the the variable is of type "pointer to type" so isnt it fairer to have the asterisk paired with the type denoting it is of the kind "pointer to type"?
I've previously shared your opinion on this issue as well, but the first answer to this StackOverflow question shows one good reason why one should opt for having the asterisk touching the variable.
http://stackoverflow.com/questions/2452335/asterisk-sometime...
That's how it feels, but the syntax for declaring multiple variables breaks it:
int* a, b;
is equivalent to
int *a;
int b;
not
int *a;
int *b;
So while I think it makes sense to think of the pointer nature as part of the type I stopped using it as the risk of writing incorrect code was too great.
Though there's also the option of forbidding shorthand declaration. Then you can write
int* a;
int* b;
especially if you have a linter letting you add such a syntax rule.
The "don't declare multiple variables on one line" is a more important rules IMO, that makes the thing that's relatively unimportant (where the * is next to) go away.
Given the numerous advantages of int* a; rather than int a;, and the general laziness of declaring variables together anyway, wouldn't it be more reasonable, as a house style, to require int and to disapprove the declaration of multiple variables in the same statement?
Note: using % instead of * below because I can't for the life of me figure out how to type an asterisk without it being used as an italics markup directive.
>> Given the numerous advantages of int% a; rather than int %a;
Care to elaborate what 'numerous advantages' there are to use int% a instead of int %a, because I can't think of a single one besides 'it feels more natural', which IMO is irrelevant in the context of a coding style.
Enforcing a single line for each variable declaration does not sound like a good idea, in mathematical code this can quickly grow unwieldy due when lots of variable are involved. It also often makes sense to group declarations of related variables on the same line to indicate they are used in the same way, for example 'int v0i, v1i' to indicate two vertex indices.
You don't have it wrong. In an object-oriented context, whether you're working in C, C++, or Obj-C, it is entirely reasonable to attach the asterisk to the type name, and treat `MyObject* ` as a type.
For every weird little edge case where `MyObject* ` doesn't make sense, there are hundreds of examples where it makes complete sense.
I've been doing it that way since I started in the 90s, and I've always felt the people who do it the old way (attaching the asterisk to the variable name) are either holding on to an obsolete bit of antique C style, or they don't know what they're doing. It has no place in modern object-oriented code.
So what about `int* a, b, c;`? Never declare multiple variables on one line like this.
C has a sort of declaration-by-example syntax. You're declaring that *someVar has type NSString. (IMHO, thinking of it this way also makes more complex declarations like function-pointer types, types with qualifiers, etc., easier to read.)
Bingo, that's the exact reason to pair the asterisk with the variable name. Especially in C-family languages where you can actually end up with code that compiles and even works, until it breaks. Think pointer arithmetic on something you assume is a pointer to a signed integer...
i used to think like you do, but this changed my mind;
int *a;
is saying, when you dereference a, you have an integer.
and when you think about it - a pointer is the same length for any data type, even pointers to functions, so it would be pointless to have a different pointer type for each data structure.
> a pointer is the same length for any data type, even pointers to functions
No that's not guaranteed despite being common. And function pointers are not even guaranteed to be representable by void* (POSIX08 does mandate it though.)
Plus not all tools can ignore whitespace changes (so indentation changes everywhere intermixed with actual code changes drown the code stuff), and if your codebase mixes whitespace-significant and whitespace-insignificant code...
Mainly it's that you don't want to mix both spaces and tabs — you want to use one or the other for a given file or else the indentation will be an incoherent mess from one machine to the next — and it's easier and more compatible to standardize on spaces than tabs.
Python really gets murderously difficult to debug in an organization with multiple types of indentation. Spaces are the least easy to screw up there, and has been why many guides I've seen have "spaces" instead of "tabs" as the default.
Because tab/space inconsistency causes problems, and because the space bar is easier to use in the flow of typing, so a style guide that mandates tabs will end up with lower compliance than one which mandates spaces.
the right way to use tabs (tabs for indentation, spaces for alignment) needs some amount of discipline to get right always. It's more flexible but very easy to make a mistake and mess it up.
Agreed. But doesn't it take discipline to follow a coding convention in general? I'd argue learning tabs-indent/spaces-align is easier than following most other semantic conventions (e.g. what constitutes a good name, how to organize code).
I see a lot of obsession with the irrelevant: when you're allowed to use dot-notation, number of spaces for indentation (sic), etc... The only reasonable item, it the singleton one, the rest... what a waste of time!
