Be explicit about the datatype when comparing #22
Comments
|
I really prefer this myself, because it's just so clear to read: NSString* str = [obj stringForblablabla];
if (str) {
//do something with the string
} |
|
For brevity I agree, but for learning and readability I prefer
On Fri, Nov 8, 2013 at 10:50 AM, Marin Todorov notifications@github.comwrote:
Cesare Rocchi |
|
Agree that it makes it easier to read but ... |
|
I wouldn't write 'if (str == nil)' myself because it leaves me open to if (str = nil). But for someone who is new to Objective-C (or programming in general) this tiny bit of verbosity would be very helpful. |
|
@moayes Yes, it's a language feature. A potentially confusing one. Just because something is a language feature doesn't mean it should always be accepted. Some language features just aren't any good. |
|
I disagree. If(obj) is a standard way to check for non-nil values. Not showing that on the site isn't helping people learn anything, it is opening them up to not understanding any real code ever, because no one mentions nil in a check for nil. I agree that checking ints should be explicit, but not objects. Sent from my iPhone
|
|
Maybe for a beginner level tutorial it is better to say |
|
@pietro - xcode produces a warning for if (str = nil) |
|
@moayes I think that's unnecessary complication for the authors to change their style depending on the tutorial level ... Did I say I love if (myObjec) { do stuff } ? It's the best |
|
I don't like checking for Just kidding! Seriously though, I think checking for non-nil pointers (or non-NULL pointers going back to C) with |
|
I am fine either way, but I still think
|
|
It doesn't need to be immediately intuitive the first time you see it. The COBOL language was very intuitive, but you wouldn't want to write anything in it today. Adding == nil is simply something you should never expect to see. If our site is coding like that, anyone who knows how to code will assume we don't. Sent from my iPhone
|
|
To be honest, I do exactly the opposite. I always do: if (str) {...};
if (str == nil) {...};go figure ... |
|
The point is that we are probably targeting people who do not know how to code in Obj-c or they are just getting started. On Nov 8, 2013, at 8:25 PM, elephantronic notifications@github.com wrote:
|
|
@elephantronic readers want to get through the tutorials as quickly as possible. if our readers have to do a double take of any of the code that ships with our tutorials and books, we failed them. i would rather write code that is 100% intuitive and unambiguous and have people think i don't know how to code than the other way around. |
|
That's crazy talk. A double take means we've failed our readers? You guys all seem to think that our readers are in a semi-vegetative state or something. Give people some credit. You understand that code, right? Did you invent not being stupid? No? So maybe other people are capable of understanding this stuff, too. if(obj) or if(!obj) IS the style we should be teaching because that's the style that people use in real life. We need to stop trying to invent our own style and teach the most commonly used practices, because people just may want to understand how to read code that isn't from this website, too. Sent from my iPhone
|
|
Yes, if (obj) and if (!obj) are used in real projects. But so are if (obj != nil) and if (obj == nil). Personally I think the former are a defect in the language (one of the few things Java does better). But I must concede that its usage is idiomatic indeed. But right now the guide says if (obj == nil) is bad, which I disagree with. |
|
The thing to remember with this topic is the end result, what do we want the code to look like regardless of skill level. We have a broad range of readers from beginner to advanced. All the coding in our tutorials SHOULD be consistent and that is the reason for doing this style guide. It is the job of the tutorial writer to explain why the code is written in the manner it is. @hollance We are going to change the word choices of good and bad. That should take care of the negative connotation that Everyone, let's have a vote on which way we prefer. Please reply with your choice. I think the reasons why have been covered. :) |
|
(obj == nil) |
|
(obj == nil) Cesare Rocchi
|
|
if(obj) Sent from my iPhone
|
|
+1 |
|
yet again: if (obj) ...
if (obj == nil) ... this way you have only positive comparisons |
|
Since you asked: if (obj != nil)
if (obj == nil)I don't think a vote on what everyone prefers is the same as finding the best way to teach programming, though. ;-) |
... for me. It's just cleaner, obvious and perfectly valid. I do however use, and prefer this: ... because I think that it's better to be explicit about the fact you're checking that there are more than zero objects in that array. |
|
My vote (but I'd be happy with whatever we decide): Because I think this is used more commonly in real life. Perhaps this is another good one for the "suggested but optional" section ;] |
|
+1 to checking bools and for nil or NULL: But I agree with others that checking for numeric zero should be explicit: |
|
+1 for I think it reads better for development tutorials when you are trying to make sense of new logic (if object, if not object - rather than using any double-negatives like "if object is not equal to nil") |
|
The majority wins on this issue. |
I have this open as a pull request but it's a bit hidden, so I'm opening up a new issue for this as well.
In the guide it currently says this is how you check for nil:
I strongly suggest we are always explicit about this sort of thing:
That makes it immediately clear what you're comparing.
I'd like the syntax
if (a)andif (!a)to be limited to booleans only.So not this either:
if (someInt) { ... }The only exception I make for this in my own code is init methods:
because that is idiomatic.
The text was updated successfully, but these errors were encountered: