Among the reasons I've always preferred Mac development is the common
use of CamelCase. I have poor eyesight and commonly eye fatigue as
well, that leads to it being difficult for me to distinguish
underscores from hyphens:
foo = unix_style;
foo = unix-style;
It is for that same reason that I adopted someone else's practice of
putting spaces inside of parentheses:
void foo( int x, char y )
I've done that for decades but I've never seen anyone else do it.
On 6/1/15, Britt Durbrow <bdurb...@rattlesnakehillsoftworks.com> wrote:
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com
--
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
_______________________________________________
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
