3 ms·
I think people should not use awkward code in tutorials and then say it was for the sake of illustrating a point. Otherwise the readers can pick up bad idioms j
by zoul 15y ago
I think people should not use awkward code in tutorials and then say it was for the sake of illustrating a point. Otherwise the readers can pick up bad idioms just as in a natural language. In this case I doubt the author wanted to showcase YES/NO. And if that really was the intention, you can easily add one sentence after the code example, explaining the potentially strange BOOL type and its values.
- Zev 15y agoThe code is very easy read. And, when you're getting started, being easy to read is very important. Besides, it is still semantically correct. (Also FWIW, I didn't find it very awkward, personally.) I might even be convinced to go a step further and say that early on, it is far more important to actually get started and avoid hitting roadblocks, then it is to write nice and pretty code. You can figure that out later on, once you're comfortable with everything.
- billjings 15y agoI think his point is that the code is written differently than it would be written in practice solely to make a pedagogical point. Tutorial code should exemplify well-written practical code in addition to whatever concept is being demonstrated. This particular construct is debatable - I personally think it can read better to explicitly break out a boolean statement like that in some cases, especially in a simple method like in this example. I certainly wouldn't take a hostage over that opinion, though.
- to3m 15y agoAnybody who can pick up Objective-C from a single HTML page is unlikely to be such a beginner that they are flummoxed, confused or unduly influenced by this code.
- bmelton 15y agoDon't confuse awkward with clever. The code that illustrates the IF conditional is far more readable than the self-returning YES or NO, where you don't even know that YES and NO are the return values. Arguably, an ObjC programmer should know that booleans are YES and NO and not true or false, but so what? Code that can't be maintained isn't good code. Code that is developed within a team should be readable before it should be clever. if it is clever, or if it needs to be clever, then it should be commented to the degree that it is more easily understood. I personally would rather write readable code than more comments.