In no particular order:
> On Jun 1, 2015, at 7:27 PM, Michael David Crawford <mdcrawf...@gmail.com>
> wrote:
>
> I quite commonly fix bugs by refactoring all the lengthy routines into
> several shorter ones.
>
I have the same rule of thumb - if it’s not obvious what’s going on, I should
probably think about refactoring it into smaller chunks.
—————————————————————————————————————————————————————————————
>
>
> On Jun 1, 2015, at 6:09 PM, Graham Cox <graham....@bigpond.com> wrote:
>
> If you have a complex method whose function can’t be determined at a glance
> (and that in itself could be a good argument for a refactoring) with multiple
> exit points rather than one clear exit point at the end, it can often be hard
> to follow the flow of control.
Um… don’t do that? :-)
Yes, early returns & gotos are power tools that can be misused. YMMV, wear
proper personal protective equipment, void where prohibited and/or
uninitialized, not for sale to miners, etc...
…and no, I have no idea why people who dig ore out of the ground shouldn’t be
allowed to buy it (I suppose that’s what I get for asking a muppet for legal
advice, eh? :-)
—————————————————————————————————————————————————————————————
>
> On Jun 1, 2015, at 4:39 PM, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Jun 1, 2015, at 14:52 , Britt Durbrow
> <bdurb...@rattlesnakehillsoftworks.com> wrote:
>>
>> I happen to like an extra semicolon after a closing brace when it’s the end
>> of the logical block. It’s just the way I like it to look (it feels ‘funny’
>> to me to have a statement end without one); the compiler ignores it. YMMV.
>
> The issue here is that you may find it comforting to see ‘;’ at the “end” of
> a statement, but it skates right over the ambiguity of when a “{ … }”
> construct is to be regard as a “logical block”. The compiler does *not*
> ignore the “;” after “}”. The following does *not* compile:
>
> if (…) {…}; else {…};
>
> You can argue that the intermediate ‘;’ not the end of a logical block, but
> if a “}” isn’t the end of a logical block, you’ve just changed a stylistic
> rule into a syntax rule.
>
The entire if statement is what I consider a logical block: the else {...} does
not, and indeed cannot, stand alone.
if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
};
[anotherObject doesSomethingElseEntirely];
is the same to the compiler as:
if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
}
[anotherObject doesSomethingElseEntirely];
or even:
someCondition?[someObject doSomething]:[someObject
doSomeOtherThing],[anotherObject doesSomethingElseEntirely];
although I will say that the readability on the third example does suffer
somewhat. :-)
—————————————————————————————————————————————————————————————
>> I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary
>> -- it doesn’t help with namespacing (if a subclass and a superclass both
>> declare _someVariable with the underscore they will collide just as badly as
>> if they declare someVariable without one)
>
> The real reason for this convention is something else. In the bad old days
> (meaning, more or less, pre-Leopard), there were multiple conflicting
> conventions about using “_” for naming. Perhaps it was when the clang
> compiler was introduced, I can’t remember exactly, but Apple decreed the
> current convention, to work around the inherent unsafety of Obj-C namespacing:
>
> — Private 3rd party instance variables *should* use the underscore.
>
> — Private 3rd party methods *must not* use the underscore.
>
> It’s not really a question of good or bad. It’s more a question of what we
> were required to do to avoid future Cocoa frameworks releases from
> retroactively breaking our apps.
>
There were multiple arguments for and against underscores; the namespace issue
is one of them; readability was another. FWIW, once upon a time, Apple claimed
the entire namespace prefixed with an underscore as reserved (for both instance
variables and methods). I believe that the modern runtime does indeed get
around the issue with ivars (I don’t have a documentation reference to point
to, but a quick check in Xcode indicates this; as does Charles Srstka’s posted
code).
—————————————————————————————————————————————————————————————
> On Jun 1, 2015, at 7:11 PM, Charles Srstka <cocoa...@charlessoft.com> wrote:
>
> On Jun 1, 2015, at 6:39 PM, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>>
>> On Jun 1, 2015, at 15:14 , Charles Srstka <cocoa...@charlessoft.com> wrote:
>>>
>>> Which is not at all, actually:
>>
>> The answer is “not at all” only with the modern ABI. 32-bit Mac compilations
>> will conflict.
>
> That’s true. Also, code written for the Mac Plus using THINK C 3.0 will
> conflict. However, compilation targets that people are actually still using
> in 2015 will not conflict.
>
> Charles
Although I have the luxury of requiring modern runtime capable systems, some
people do still have to target the old runtime…
Also, FWIW the modern runtime only handles same-named instance variables that
are privately declared; same-named variables declared in an @interface section
will conflict even on the modern runtime.
Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a
local variable of the same name as an instance variable.
> On Jun 1, 2015, at 3:14 PM, Charles Srstka <cocoa...@charlessoft.com> wrote:
>
> Non-underscored ivars vs. local variables, however, are not obvious at all,
> especially if the method is large.
In modern versions of Xcode at least, if I don’t know exactly what I’m looking
at, the answer is just a command-click away… :-)
Also, the syntax highlighting does render (at least on my setup) in different
colors for local variables and instance variables.
—————————————————————————————————————————————————————————————
>> Steve - are you saying that C++ destructors aren't called if you use a goto?
>>
>> It was my understanding that the destructor is called if you go out of
>> scope for any reason, even if it's a goto.
>
> Hmm, either I'm thinking of something else, or I just can't find the right
> docs. I just learned to never ever use them, and my life as a developer is
> just dandy. :)
>
> Steve via iPad
I just did a test with this code:
#import <Foundation/Foundation.h>
#import "stdio.h"
class testClass
{
public:
testClass()
{
puts("Constructor called.");
};
~testClass()
{
puts("Destructor called.");
};
void someFunction()
{
puts("someFunction called.");
};
};
int main(int argc, const char * argv[])
{
@autoreleasepool
{
puts("Starting...");
if(argc)
{
testClass t;
if(argc==1) goto done;
t.someFunction();
};
done:
puts("Done!\n");
};
return 0;
};
and got this output:
Starting...
Constructor called.
Destructor called.
Done!
So…. it looks like clang at least is doing the right thing and calling the
destructor when the variable goes out of scope.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
