coding convention for Objective C

[Do Hoang Minh Quan]

Hi all,

Anyone experienced in Coding Convention for Objective C ? Please share your knowledge.

Regards,

Quan

[Tony Arnold]

Hi Quan,

On 01/04/2011, at 6:14 PM, Do Hoang Minh Quan wrote:

> Anyone experienced in Coding Convention for Objective C ? Please share your knowledge.

What kind of advice are you looking for? This is a very broad topic.

all the best,

Tony

----------
Tony Arnold
http://thecocoabots.com/

[Do Hoang Minh Quan]

Hi Tony,

My team and I transferred to ObjC from C++ and Java. We've worked with ObjC for 3 years++. However, sometimes we still get stuck with naming convention.

1/ Is it a good choice if I bring C++/Java naming convention to ObjC? ex: use "a" prefix for parameter, "_" prefix for local...
2/ Do you have any suggestion for naming a class? I currently use "FeatureName" + "base class" = class name (HomeViewController), however some team mates use "Screen" as prefix to identify it inherits from UIViewController (ScreenHome)...etc..

I intend to build a document to force the team to follow naming convention, code convention as defined in the document so I can handle the project easily (maintenance, fix bugs, change devs...)

Thanks,

Quan

> --
> You received this message because you are subscribed to the Google Groups "Australian Cocoaheads" group.
> To post to this group, send email to cocoah...@googlegroups.com.
> To unsubscribe from this group, send email to cocoaheadsau...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cocoaheadsau?hl=en.
>

[Robert Stainsby]

Quan, start by looking at Apple's documentation on this topic:

Cocoa Core Competencies: Coding conventions

“Cocoa API Conventions”

Coding Guidelines for Cocoa

Hope this helps.

Robert

===============

Robert Stainsby

Melbourne Australia

Twitter: http://twitter.com/rjsdev

http://web.me.com/rjsdev

[Robert Stainsby]

Also worth a look:

Google Objective-C Style Guide

[Do Hoang Minh Quan]

Thank a lot Robert! 

[Pedro fp]

Also worth looking at Marcus Zarra's style guide...

http://www.cimgf.com/zds-code-style-guide/

This one has heavily informed my own style approach.

On 01/04/2011, at 6:35 PM, Do Hoang Minh Quan wrote:

Thank a lot Robert! 

On 01/04/2011, at 3:31 PM, Robert Stainsby wrote:

Quan, start by looking at Apple's documentation on this topic:

Cocoa Core Competencies: Coding conventions

“Cocoa API Conventions”

Coding Guidelines for Cocoa

Hope this helps.

Robert

===============

Robert Stainsby

Melbourne Australia

Twitter: http://twitter.com/rjsdev

http://web.me.com/rjsdev

Cheers, Pedro :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"There's no place like 127.0.0.1."

[Dave Newman]

Zarra's style is interesting. I Like most of it. I have some comments:

Dot Notation

Lets get the big one out of the way. Dot syntax is not to be used on any projects that Zarra Studios produces with a singular exception:

CALayer *layer = [CALayer layer];
layer.contents = someCGImageRef;

No dots? Really? I like dots.

Braces

- (void)someMethod
{
  //Do something
}

 Wrong. He gets that wrong. Just like @alancse

@property

Property definitions should be used in place of iVars. As of Xcode 3.2.5, we should no longer be declaring iVars at all. This will help to insure proper memory management. In addition, direct iVar access should be avoided except during initialization of the variable and in the -viewDidUnload and -dealloc methods.

I like this. I don't declare ivars for properties

Also ZAssert, DLog, ALog: I'll be poaching these ; )

I also love how comments aren't allowed on that post.

--

You received this message because you are subscribed to the Google Groups "Australian Cocoaheads" group.
To post to this group, send email to cocoah...@googlegroups.com.
To unsubscribe from this group, send email to cocoaheadsau...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cocoaheadsau?hl=en.

--
Dave Newman ∴ http://whatupdave.com ∴ @whatupdave

[Sean Woodhouse]

One thing I really don't like about XCode is that the indentation and bracket formatting are set application-wide, not for each project. So I continually have to remember to switch them as I go from one project to another, which is a complete pain in the arse. Not all projects have the same coding guidelines!

Sean.

[Robert Stainsby]

Although I haven't really used it, it seems Xcode 4 has a Text Settings section in the File Inspector in the right-hand Utilities area, which lets you set indentation on a project basis. Can't help with brackets though Sean - grrrr!

Cheers, Robert

[Oliver Jones]

On 02/04/2011, at 12:55 PM, Dave Newman wrote:

Zarra's style is interesting. I Like most of it. I have some comments:

Dot Notation

Lets get the big one out of the way. Dot syntax is not to be used on any projects that Zarra Studios produces with a singular exception:

CALayer *layer = [CALayer layer];
layer.contents = someCGImageRef;

No dots? Really? I like dots.

I use dot notation to access properties, never methods.

Braces

- (void)someMethod
{
  //Do something
}

 Wrong. He gets that wrong. Just like @alancse

I prefer my braces on the next line.  Which doesn't seem to be the "default" style for ObjC code.  But then I am a recovering .NET coder. ;)  Though I also had braces on the next line in my C/C++.

@property

Property definitions should be used in place of iVars. As of Xcode 3.2.5, we should no longer be declaring iVars at all. This will help to insure proper memory management. In addition, direct iVar access should be avoided except during initialization of the variable and in the -viewDidUnload and -dealloc methods.

I like this. I don't declare ivars for properties

Hmm..  Somehow I missed this feature.  Sometimes you have to declare property ivars.  For example when you provide a custom implementation of a property setter or something.  I always prefix my ivars with m_ to differentiate them from properties.  

Regards

[Sadat Rahman]

On 02/04/2011, at 12:55 PM, Dave Newman wrote:

Zarra's style is interesting. I Like most of it. I have some comments:

Dot Notation

Lets get the big one out of the way. Dot syntax is not to be used on any projects that Zarra Studios produces with a singular exception:

CALayer *layer = [CALayer layer];
layer.contents = someCGImageRef;

No dots? Really? I like dots.

IMHO, the dot notation is a bastardisation of the language to appease Java / .NET developers.

The messaging passing syntax is a lot clearer & consistent in the sense it avoids ambiguity when you are dealing with structs.

E.g.:

anImageView.frame.size.width = 30.; // Results in a compiler error since the value returned by the dot notation invocation is not a lvalue.

If, however, anImageView was a struct the above line of code would be valid.

Braces

- (void)someMethod
{
  //Do something
}

 Wrong. He gets that wrong. Just like @alancse

Disagree. It is a matter of personal choice and you will never win this one!

Personally, I prefer Allman / ANSI style over 1TBS style simply because the brackets match up nicely.

@property

Property definitions should be used in place of iVars. As of Xcode 3.2.5, we should no longer be declaring iVars at all. This will help to insure proper memory management. In addition, direct iVar access should be avoided except during initialization of the variable and in the -viewDidUnload and -dealloc methods.

I like this. I don't declare ivars for properties

Also ZAssert, DLog, ALog: I'll be poaching these ; )

Agreed.

[Sadat Rahman]

>
> Hmm.. Somehow I missed this feature. Sometimes you have to declare property ivars. For example when you provide a custom implementation of a property setter or something. I always prefix my ivars with m_ to differentiate them from properties.

I always thought m_ had the negative connotation of being Hungarian notation. ivar_ is probably the better choice these days (again personal/team decision). As long as you don't prefix _ for method names or ivars as that is reserved by Apple.

Also, you can declare your private / internal ivars in your .m file as part of your class continuation category:

File: FooBar.m

@interface FooBar ()
{
id internalVar1_;
}

@property (nonatomic, retain) id internalVar1;

- (void)internalMethod;
@end

@implementation FooBar
{
id internalVar2; // Can also declare internal ivars within the implementation block.
}

@synthesize internalVar1 = internalVar1_;

- (void)internalMethod
{
DLog(@"%@ %@", internalVar1, internalVar2);
}

...
@end

For the above to work you have to set your compiler to clang/LLVM 1.5 or higher. Also need to specify: -Xclang -fobjc-nonfragile-abi2 within your "Other C Flags" settings.

[Pedro fp]

While I said Zarra's style heavily informed mine I don't follow it slavishly either, though I have used his document as the starting point for writing my own style guide. Right now that's only for me to follow but all going well that may change.

I'm something of a Zarra fan having received good answers to a couple of my questions on stackoverflow.com from him & a good few more solutions from his answers to others & his articles on cimgf. He's particularly good on CoreData (& author of "Core Data: Apple's API for Persisting Data on Mac OS X").

Here's some additional comments of my own...

On 02/04/2011, at 11:55 AM, Dave Newman wrote:

Zarra's style is interesting. I Like most of it. I have some comments:

Dot Notation

Lets get the big one out of the way. Dot syntax is not to be used on any projects that Zarra Studios produces with a singular exception:

No dots? Really? I like dots.

I like the Objective-C style & use it instead of dot notation more & more.

Braces

- (void)someMethod
{
  //Do something
}

 Wrong. He gets that wrong. Just like @alancse

I don't think there's a right or wrong here. I used to never line break before opening braces but now follow Zarra's practice of line breaks before the brace opening a method but not before opening braces within methods (there's an example in what I've added below).

Code width

Code should not be set to an arbitrary width. We have wide monitors and an editor that smart wraps the code. Do not limit code to 80 columns or any other arbitrary width unless it is to be printed.

Here's one that I disagree with Zarra on. I hate reading long lines (it's also well shown that about 20 cm is the limit of comfortable scanning with when reading) & also dislike the way Xcode wraps long lines. However I really do like the way Xcode indents to line things up nicely when returns are put between Obj-C arguments. IMO that enhances readability & so i often add returns in lines that aren't long enough to really need it just to have the arguments stacked in a neat column.

Golden Path

When coding with conditionals, the left hand margin of the code should be the “golden” or “happy” path. We should never see:

- (void)someMethod
{
  if ([someOther boolValue]) {
    //Do something important
  }
}

That is difficult to read. Instead the code should fail early and fail often:

- (void)someMethod
{
  if (![someOther boolValue]) return;
  //Do something important
}

I've completely switched from the first approach here to the 2nd. Same for the other variants that Zarra goes on to cover. When I did my first programming (on a mighty MONECS system many moons ago) I was taught that approaches like the 2nd here were less computationally efficient & context of the computing power involved at the time that might have made a difference. these days there's no way it can make enough difference to trump the improvement in readability for me.

On Fri, Apr 1, 2011 at 7:44 PM, Pedro fp <bandi...@gmail.com> wrote:

Also worth looking at Marcus Zarra's style guide...

http://www.cimgf.com/zds-code-style-guide/

This one has heavily informed my own style approach.

Cheers, Pedro :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"10 percent of computer users are Mac users,

but remember, we are the top 10 percent."

                               Douglas Adams

[Oliver Jones]

Yeah. I'm not a big fan of the trailing underscore style. While I'd never take on Hungarian notation (being a fully scared Win32 C/C++ developer) I use m_ for my member vars (ivars) that don't have properties associated with them.

> Also, you can declare your private / internal ivars in your .m file as part of your class continuation category:
>
> File: FooBar.m
>
> @interface FooBar ()
> {
> id internalVar1_;
> }

You learn something everyday. I didn't realise you could add additional ivars. I knew about adding private methods this way.

Regards

[Robert Stainsby]

On 02/04/2011, at 8:10 PM, Oliver Jones wrote:

Hmm..  Somehow I missed this feature.  Sometimes you have to declare property ivars.  For example when you provide a custom implementation of a property setter or something.  I always prefix my ivars with m_ to differentiate them from properties.  

A point of clarification from Apple's The Objective-C Programming Language: Declared Properties:

• For the modern runtimes (see “Runtime Versions and Platforms” in Objective-C Runtime Programming Guide), instance variables are synthesized as needed. If an instance variable of the same name already exists, it is used.

These synthesised ivars have the same name as the property by default, and can be used in custom setters, getters and elsewhere (typically only init and dealloc methods).

In other words (if I've got the details right), the only time you have to declare property ivars now is for compatibility with Mac OS X 10.5 Leopard and earlier, or for the Mac 32-bit runtime.

I'm loathe to comment on a style issue, but I will say this about ivar naming. Synthesised ivars have the same name as the property by default, as do most of the ivars in Apple sample code. Any naming convention that requires a prefix for ivars (such as m_ or ivar_) is just creating extra work and code, given these existing conventions.

[Oliver Jones]

A point of clarification from Apple's The Objective-C Programming Language: Declared Properties:

• For the modern runtimes (see “Runtime Versions and Platforms” in Objective-C Runtime Programming Guide), instance variables are synthesized as needed. If an instance variable of the same name already exists, it is used.

These synthesised ivars have the same name as the property by default, and can be used in custom setters, getters and elsewhere (typically only init and dealloc methods).

In other words (if I've got the details right), the only time you have to declare property ivars now is for compatibility with Mac OS X 10.5 Leopard and earlier, or for the Mac 32-bit runtime.

I'm loathe to comment on a style issue, but I will say this about ivar naming. Synthesised ivars have the same name as the property by default, as do most of the ivars in Apple sample code. Any naming convention that requires a prefix for ivars (such as m_ or ivar_) is just creating extra work and code, given these existing conventions.

This is true.  I guess using m_ for me is just force of habit from earlier languages and coding styles.

Regards

[Rogerio de Paula Assis]

There's one situation I can think of where it is important to have an ivar named differently from its synthesised property, and that is when your custom getter initialises / loads your ivar lazily. 

In this case it is an extra layer of protection to avoid you accessing the ivar directly. 

Also on the note of not declaring ivars but only properties, do you guys find it harder to debug your code as you don't have access to property values and the ivars do not show up either?

Sent from my iPad

[Chris Gummer]

I've found this situation improved in Xcode 4 and there is always GDB. But yes it can be painful and has caused me to add ivars.

[Nathan de Vries]

On 03/04/2011, at 1:03 AM, Sadat Rahman <sadat....@gmail.com> wrote:
> ...you can declare your private / internal ivars in your .m file as part of your class continuation category

For those looking it up in The Objective-C Programming Language guide, they're referred to as class extensions. I've always found it odd that Apple calls them "class continuations" internally, but never in documentation.

Cheers,

Nathan

[Bill Tinker]

This style violates two principles I was taught and have adhered to consistently.

 

·         A routine should only have one exit point.

·         IF statements should be phrased in the positive

 

I don’t find your second example easier to read at all.

 

Bill

[benbritten]

Hey Bill,

I was also taught those same things when I was in school. However, I
have since switched to the 'happy path' or 'negative shunting' method
and my code is shorter, simpler and more readable. It is a
contentious issue because so many of us were taught that there must
only be one exit point.

To me it makes more sense (now that I have been doing it this way for
a half dozen years or so) to have any given method do only that thing
that it is supposed to do and if it is not qualified to do it, then
don't waste your cycles and get out (ie a negative if statement, and
an early exit)

So many of my methods tend to follow this pattern:

- (SomeClass*)doSomethingWithX:(id)x
{
if (not qualified to deal with X) return nil;
do something with X get someValue;
return someValue;
}

instead of the traditional:

- (SomeClass*)doSomethingWithX:(id)x
{
SomeClass* localObject = nil;
if (qualified to deal with X) {
do something with X get someValue;
put someValue in localObject;
}
return localObject;
}


To be honest; I actually have no idea what the reasoning behind 'only
one exit point' ever was. I found when I was trying to adhere to that
mentality that I would bend my code into crazy logic and have really
terrible if/then/else trees and temporary local objects so that I
could get every path to exit the method at the same place. When I
first came across the 'happy path' way of doing things it was like a
revelation. Why had I been limiting myself to a single point of
exit? The only reason I ever came up with was : because I was taught
that way. So I stopped doing that and have never looked back.

Cheers!
-B

On Apr 4, 9:57 am, "Bill Tinker" <b...@AriesSoftware.com.au> wrote:
> This style violates two principles I was taught and have adhered to
> consistently.
>

> .         A routine should only have one exit point.
>
> .         IF statements should be phrased in the positive

>
> I don't find your second example easier to read at all.
>
> Bill
>
> From: cocoah...@googlegroups.com [mailto:cocoah...@googlegroups.com]
> On Behalf Of Pedro fp
> Sent: Sunday, 3 April 2011 1:37 AM
>
> Golden Path
>
> When coding with conditionals, the left hand margin of the code should be
> the "golden" or "happy" path. We should never see:
>
> - (void)someMethod
> {
>   if ([someOther boolValue]) {
>     //Do something important
>   }
>
> }
>
> That is difficult to read. Instead the code should fail early and fail
> often:
>
> - (void)someMethod
> {
>   if (![someOther boolValue]) return;
>   //Do something important}
>
> I've completely switched from the first approach here to the 2nd. Same for
> the other variants that Zarra goes on to cover. When I did my first
> programming (on a mighty MONECS system many moons ago) I was taught that
> approaches like the 2nd here were less computationally efficient & context
> of the computing power involved at the time that might have made a
> difference. these days there's no way it can make enough difference to trump
> the improvement in readability for me.
>

[Andres Kievsky]

There are many counterexamples to your rules. For instance, famous programmer Wil Shipley's "bail out early" idea:

"What you should really do is write "if" statements that check for improper conditions, and if you find them, bail."

http://blog.wilshipley.com/2005/07/code-insults-mark-i.html

Great way to make sure your routine checks for invariants at the beginning, which IMO are extremely important and often forgotten.

As for the second rule, I would rewrite it as:

"If statements should be phrased in the clearest way possible"

Most of the time that coincides with the positive form, but not always..

-- ank

[Oliver Jones]

I personally hate:

if (!something) { }

A) It is easy to miss the little ! character when reading the code.  

B) something == nil is way easier to "grok"

When I first started programming in C/C++ I used the not/bang operator a lot.  Not so much now with 15+ years experience.

I also understand people's aversion of the = character in if conditions due to the possibility of:

if (something = nil)

when you wanted

if (something == nil)

But if your compiler isn't warning you about assignment inside an if, get a new compiler.

As for single exit point methods/functions. 

This is fine:

void somethingSimple()

{

if (something)

{

return a;

}

return b;

}

And so is this:

void somethingSimple2()

{

switch(something)

{

case 1: return blah;

case 2: return baz;

default: return foo;

}

}

This is not:

void somethingComplex()

{

while(fizzbing)

{

if (something)

{

while (bong)

{

if (whatever)

{

return boggle;

}

bonk();

bing();

}

}

else

{

return twiddle();

}

bang();

}

return blah;

}

It is all about simplicity of code.  If find my first example simpler than:

void somethingSimple()

{

var result = b;

if (something)

{

result = a;

}

return result;

}

Also, what is that truism about hard and fast rules being for novices and experts knowing when to break them...?

Regards

On 04/04/2011, at 9:57 AM, Bill Tinker wrote:

[Chris Miles]

An argument for the convention of putting the constant on the left.

if (nil == something)

The compiler won't let you get away with forgetting an "=" character.

Cheers,

Chris

[Sadat Rahman]

On Mon, Apr 4, 2011 at 11:39 AM, Chris Miles <miles...@gmail.com> wrote:
>
> An argument for the convention of putting the constant on the left.
> if (nil == something)

Same goes for any other constants or r-values. They should go on the
left of the equality comparison.

[Oleg Kiorsak]

all very good points!

esp. 

>"The messaging passing syntax is a lot clearer & consistent in the sense it avoids ambiguity when you are dealing with structs."

as it also reflects the fact that in real terms, at runtime, it is indeed a message been dispatched dynamically, 

rather then something statically resolved at compile-time...

(if I am not mistaken in how Objective-C works)

cheers

O.K.

 

--

[benbritten]

Yeah, I have seen that, but I tend to agree with Oliver, if your
compiler doesn't warn you then you need a new compiler. (or if you are
doing any sort of test driven development, then it wont pass the first
test)

I find "if (nil == something)" to be terribly inconsistent with the
way I think :-) and I kinda hate it :-)

If you have to change your entire coding style and (in my opinion)
give up readability because you might make a typo (that the compiler
will warn you about anyway) then perhaps the coding style is not the
problem :-)

While I do occasionally make the if (x = nil) error, it is rare enough
(and easy enough to find) that it is of little concern to me (and
definitely not enough to inform my coding style)

Cheers!
-B

[Nathan de Vries]

On 04/04/2011, at 11:19 AM, Oliver Jones wrote:

> Also, what is that truism about hard and fast rules being for novices and experts knowing when to break them...?

"Young men know the rules, but old men know the exceptions." — Oliver Wendell Holmes

Cheers,

Nathan

[Nathan de Vries]

On 04/04/2011, at 9:57 AM, Bill Tinker wrote:

> A routine should only have one exit point.

I think this rule is impractical, especially in event-driven environments. Guard clauses are the most concise way for an event consumer to dismiss irrelevant events (e.g. under these conditions, this mouseDragged: event should not be handled).

Martin Fowler's book Refactoring covers guard clauses in "Replace Nested Conditional with Guard Clauses", and Kent Beck defines them as a best practice in Smalltalk Best Practice Patterns. Both are worth reading if you get the chance.

Cheers,

Nathan

[Bill Tinker]

The reason is: if you have to run some tidy-up steps, they should all be
done at the one point, not duplicated at every other exit point.

[Andres Kievsky]

>
>
> To be honest; I actually have no idea what the reasoning behind 'only
> one exit point' ever was.
>
>

To make O()-analysis easy/possible, same reason why Dijkstra didn't like GOTOs.

-- ank

[Bill Tinker]

We've just built an application and designated ios 3.0 as the minimum
version, but when running on a 3.1.3 device the images are not displaying in
the tab bar. On a 4.2.1 device the images are fine.

Anybody know of a reason why the images aren't showing on 3.1.3?

Bll

-----Original Message-----
From: cocoah...@googlegroups.com [mailto:cocoah...@googlegroups.com]

Cheers,

Nathan

--

[Quan Minh]

Did you use xib or Code to initialize the tabbar?

Sent from my iPhone

[Bill Tinker]

Code - good question though, because an image in the About.xib works ok.

Tab.image = [UIImage imageNamed:@"Info"];

The help file indicates .image and imageNamed have been available since ios
2.0

Bill

[Luke Tupper]

Specify the image name with its proper name:

Tab.image = [UIImage imageNamed:@"Info.png"];

The simulator and later iOS will find the correct image, earlier version won't

[Do Hoang Minh Quan]

Biil,

I won't recommend this

> Tab.image = [UIImage imageNamed:@"Info"];

You should add file extension to image path

Tab.image = [UIImage imageNamed:@"Info.png"];

I don't know if you are using xCode 4 or 3.x. However, XCode bypass many warnings that may causes some in-comprehensive bugs.

Quan

[Alan Rogers]

You need to include the file name extension in code running on anything less than iOS 4.

ie.

Tab.image = [UIImage imageNamed:@"Info.png"];

Cheers,
Al

[Harry Ohlsen]

Check that you haven't left out the .png in the file names. The earlier SDKs were more forgiving and just assumed .png if it wasn't there.

[Harry Ohlsen]

On Mon, Apr 4, 2011 at 14:02, Harry Ohlsen <steatopygou...@gmail.com> wrote:

Check that you haven't left out the .png in the file names. The earlier SDKs were more forgiving and just assumed .png if it wasn't there.

As a couple of people have said, it's the other way around.

The earlier SDKs were fussier ... I think it was an error for Apple to make them less fussy, because what tends to happen is you build and test stuff with the latest SDK and when you think you're almost ready to go, you discover these silly errors and have to track them down. Of course, the answer is not to make the error in the first place, I guess :-).

[Bill Tinker]

Thanks guys - that's now working.

-----Original Message-----
From: cocoah...@googlegroups.com [mailto:cocoah...@googlegroups.com]
On Behalf Of Do Hoang Minh Quan
From: cocoah...@googlegroups.com [mailto:cocoah...@googlegroups.com]
On Behalf Of Alan Rogers

You should add file extension to image path
Tab.image = [UIImage imageNamed:@"Info.png"];

You need to include the file name extension in code running on anything less
than iOS 4.

[Oliver Jones]

I've always found my brain doesn't do the backwards == thing.  I've personally never had a case where I accidentally used = when I should have ==.

YMMV.

Regards

[Oliver Jones]

Then you code should be:

void function1()
{
if (foo)
{
return a;
}

return b;
}

void function2()
{
x = function1();
// use x

tidyup();
}

Regards

On 04/04/2011, at 12:40 PM, Bill Tinker wrote:

> The reason is: if you have to run some tidy-up steps, they should all be
> done at the one point, not duplicated at every other exit point.
>

> -----Original Message-----
> From: cocoah...@googlegroups.com [mailto:cocoah...@googlegroups.com]

> On Behalf Of benbritten
> Sent: Monday, 4 April 2011 10:18 AM
>
>
> To be honest; I actually have no idea what the reasoning behind 'only
> one exit point' ever was.
>
>

[Andres Kievsky]

I am with you on this one, the backwards == is a C/C++ idiom that I've never really liked - and one of the areas where having Pascal-like := and = operators is an improvement over the C-style = and ==

(Thank you, Mr. Wirth!.)

-- ank

[Oliver Jones]

If I remember correctly from my old Pascal/Modula-2 days, Pascal, like Java and C#, disallows assignment in boolean expressions outright, never-mind the := assignment operator's different syntax.

Regards

[Andres Kievsky]

On 04/04/2011, at 2:51 PM, Oliver Jones wrote:

> If I remember correctly from my old Pascal/Modula-2 days, Pascal, like Java and C#, disallows assignment in boolean expressions outright, never-mind the := assignment operator's different syntax.
>

trudat

-- ank

[John Gronow]

And that's why it alway struck me as bizarre when I moved from Pascal/Modula-2 to C!

John.

[Pedro fp]

On 04/04/2011, at 2:23 PM, Oliver Jones wrote:

> void function1()
> {
> if (foo)
> {
> return a;
> }
>
> return b;
> }

I've come more & more to avoid writing more than 1 line where 1 will suffice (so long as the resulting line isn't itself a godawful mess). So where the stuff represented by "return a" & "return b" are (or can be) single line statements I'd write...

void function1()
{
if (foo) return a;

return b;
}

or even...

void function1()
{
return (foo ? a : b);
}

Others?

Cheers, Pedro :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"America did not invent human rights, human rights invented America."
Jimmy Carter

[Gareth Townsend]

As long as you don't do one line if statements spread over 2 lines without braces I'm ok with it. I really hate code like this:

> void function1()
> {
> if (foo)
> return a;
>
> return b;
> }

Then again, I think I hate the second example. It's just starting to get too clever for its own good. One liners are nice, but not when I have to think to understand them.

I'd rather parse a few simple lines of code, than one complex line of code.

[Oleg Kiorsak]

it's not just about "hate"...

anyone coming from C background (and btw Objective-C is still "C" ;)

will be very much against having no brackets even its on a same line - i.e.:

if (foo) boo();

because in C, boo() could easily happen to be a... MACRO !! 

HTH

cheers

O.K.

[Andrew Lim]

If the guard clause required memory allocation/object instantiation/opening of a file/being wrapped in a state change/etc. to validate, and especially if there are several steps of validation then I could understand the need to unify the exit point.  I would then use something like a BOOL result = NO; for example.
(Then there's the question whether the allocation/opening/etc. belongs in that function to begin with?)

I see it as a case-by-case thing, if it's a simple guard clause (which is what I try to keep most) and it is safe to "short-circuit" at that point, then return.

[Oliver Jones]

Please take those examples as radical simplifications where "return a" may represent a more complex construct.

But yes, I completely agree with you for simple stuff.  That ultra simple method would be much better as you describe.

Though I have found some developers run screaming from the ternary operator.  I however quite like it (when used appropriately).

Regards

[Oliver Jones]

But then if you're writing macros that look like functions that don't provide their own scoping you need to be slapped. ;)

Regards

[Oliver Jones]

The ad in GMail below this thread is humorous:

Tired of Java, C++ C#? - Try Eiffel: simple and powerful

Another approach for better results

www.eiffel.com

Ahh.... no thanks.

[Oleg Kiorsak]

on a large legacy codebases you'd find all sort of crap... and the individuals that needed to be slapped have long gone (moved on)...

then some junior/grad programmer has to do a maintenance "bug fix" that seems fairly trivial on a surface...

what are the odds that he/she will bother looking up what the definition of "boo()" is... ie whether it is a macro or not?

having coding standards requiring brackets make it "fool proof" and "slack proof"... IMHO...

cheers

O.K.

On Mon, Apr 4, 2011 at 3:45 PM, Oliver Jones <orj...@gmail.com> wrote:

[Oleg Kiorsak]

hehe 

exactly same ad here...

do you also get the second one?:

Fortran/C/C++ Developers

Great opportunities in London at supercomputing start-up

[Pedro fp]

On 04/04/2011, at 3:43 PM, Oliver Jones wrote:

> Though I have found some developers run screaming from the ternary operator. I however quite like it (when used appropriately).

Crucial keywords being "when used appropriately". I use the brain pain gauge, if the concise form hurts my brain more to read than the more verbose form then I go with verbose. OTOH I know a PHP coder who uses (condition ? true : false) with quite complex statements in all 3 parts & nested a dozen (& probably more) deep. One glance at a screenful of his code is near migraine inducing for me but he finds it perfectly comprehensible.

Cheers, Pedro :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If we are to be non-violent, we must then not wish for anything
on this earth which the meanest or the lowest of human beings
cannot have."
M K (Mahatma) Gandhi

[Jared Kells]

50 Emails on coding style is a bit annoying, it's a highly subjective topic.

Bringing it back on topic for mobile though. Make sure you have TWO new lines after every function declaration. This is breathing room and stops the code from overheating which is very important in embedded systems.

void function foo()
// IMPORTANT This is breathing space DO NOT REMOVE
{

[Jeff]

+1 for Yoda conditions

Although I'll flip if a fellow team member objects strongly I can see
both sides.

[Pedro fp]

Definitely subjective however I'm quite enjoying the thread. It's quite light & being in regional Qld where I have exactly zero in person contact with other Obj-C developers the thread is proving to be a useful gauge for my own coding approach.

On 04/04/2011, at 4:01 PM, Jared Kells wrote:

> 50 Emails on coding style is a bit annoying, it's a highly subjective topic.

Cheers, Pedro :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If it is permissible for human beings to harass and humiliate and
ruin other human beings in the name of profit, and to do so without
let or fine or hindrance, then it is not a democratic system we are
talking about, it is a tyranny."
Bob Ellis in 'First Abolish the Customer', Penguin 1998, p100

[Oliver Jones]

Lol. Good one.

[Bill Tinker]

In the eighties when computing was done on bureau services, an application was found to have such code scattered at various intervals…

 

  For i = 1 to 100,000 : Next

 

When this was queried with the project manager he explained it was a “Revenue Block” – designed to chew up CPU cycles that were the basis for the billing.

 

Bill

 

From: cocoah...@googlegroups.com [mailto:cocoah...@googlegroups.com] On Behalf Of Oliver Jones

Sent: Monday, 4 April 2011 4:36 PM
To: cocoah...@googlegroups.com

[Oleg Kiorsak]

what great idea!

hei, this can still have potential nowadays again - with "cloud computing" pricing models that charge per CPU cycles and/or "instance size"...

;)

[Nathan de Vries]

At the YOW! developer conference last year, Dan Ingalls (of Smalltalk & BitBlt fame) had a great story about his first piece of software — a Fortran profiler marketed at universities & research facilities to reduce the time spent running software on time-share machines. He found out pretty quickly that there was no interest, because it would mean they'd lose out on grant money.

Cheers,

Nathan

[Oliver Jones]

Charging per MIPS (millions of instructions per second) is still done in this century too.  When I was at GS the z Series mainframe was charged to us by IBM on a MIPS basis.

There was quite a desire from management to lower the amount of processing done on the mainframe to reduce costs.

Regards

On 04/04/2011, at 5:06 PM, Bill Tinker wrote:

[Matt Connolly]

On 04/04/2011, at 11:39, Chris Miles <miles...@gmail.com> wrote:

An argument for the convention of putting the constant on the left.

if (nil == something)

The compiler won't let you get away with forgetting an "=" character.

Is that it?!!? I never understood why the result was placed on the left side of the equation.

It's still totally backwards to how my brain works (where the answer comes after the question) but interesting to know there's method to the madness...

Cheers,

Chris

On 04/04/2011, at 11:19 AM, Oliver Jones wrote:

I also understand people's aversion of the = character in if conditions due to the possibility of:

if (something = nil)

when you wanted

if (something == nil)

But if your compiler isn't warning you about assignment inside an if, get a new compiler.

[Andres Kievsky]

On 06/04/2011, at 10:24 PM, Matt Connolly wrote:

> It's still totally backwards to how my brain works (where the answer comes after the question) but interesting to know there's method to the madness...
>

Agreed, it's horrible - although C/C++ developers use it all the time.

-- ank

[andy nicholson]

Well, nobody here will care :) but for Java developers, there is also the same pattern to avoid a null pointer exception.

Compare:

if ( str!=null && str.equals("im a constant string") ) { ... }

if ( "im a constant string".equals(str) ) { ... }

calling a method on a string is perverse though i use it all the time.

:D

 

On Wed, Apr 6, 2011 at 10:24 PM, Matt Connolly <matt.connolly.au@gmail.com> wrote:

On 04/04/2011, at 11:39, Chris Miles <miles...@gmail.com> wrote:

An argument for the convention of putting the constant on the left.

if (nil == something)

The compiler won't let you get away with forgetting an "=" character.

Is that it?!!? I never understood why the result was placed on the left side of the equation.

It's still totally backwards to how my brain works (where the answer comes after the question) but interesting to know there's method to the madness...

--
Andy Nicholson

+61 406 306 715 [ .au ]

[Chris Suter]

On Wed, Apr 6, 2011 at 10:41 PM, andy nicholson <intot...@gmail.com> wrote:

> Well, nobody here will care :) but for Java developers, there is also the
> same pattern to avoid a null pointer exception.
>
> Compare:
>
> if ( str!=null && str.equals("im a constant string") ) { ... }
>
> if ( "im a constant string".equals(str) ) { ... }
>
> calling a method on a string is perverse though i use it all the time.

Ironically, you’d do it the other way round in Objective-C.

I'm sure it's already been mentioned, but nowadays there really is no
good reason for writing:

if (value == variable)

The compiler (with the correct warning flags) will warn you if you
accidentally write:

if (variable = value)

I include the following compiler flags in all my projects: “-W -Wall
-Wno-unused-parameter”.

If you actually want to assign a variable within an if statement, you
enclose it in double brackets, like so:

if ((variable = value))

My init methods look like:

if ((self = [super init])) {
// Code here
}
return self;

Although I note that Xcode 4’s template is now:

self = [super init];
if (self) {
// Code here
}
return self;

-- Chris