Comments (11)
It can also be a problem if you use multi-statement macros that are written poorly. For example:
#define foo(x, y) x; y
if (bar) foo(quux(), quux());
This is, of course, a better argument for writing multi-statement macros correctly:
#define foo(x, y) do { x; y; } while(0)
(Lots of folks don’t understand why they see do/while in macro expansions, or more recently, GNU C statement expressions or blocks. This is why.)
from objective-c-style-guide.
I would also suggest that it’s entirely possible that you’re savvier than the average bear, Josh. I can’t recall instances where I’ve witnessed this burn a novice, or in fact any instances where I’ve seen it burn someone without the macro thing above being involved, but I could see it occurring.
Personally, I feel like thoughtful style guides are most helpful to the least experienced, but that does not necessarily equate to them being unhelpful to the masters of the craft.
from objective-c-style-guide.
Great point, Rob. Regarding "most helpful to the least experienced" I'd argue "only if the style guide adequately explains why this is the better way." In its present state this assertion reads more like dogma. Particularly the "just too many ways" sentiment.
from objective-c-style-guide.
Yes, thorough justification for style choices (or at least explanation, for those choices which are just “we like looking at it better when it looks like this”) is an important tool to educate about the language. Not merely rote memorization of a pattern, cargo culting the way to prosperity as it were, but rather informing. One ought to respect one’s peers enough to explain one’s reasoning, after all.
from objective-c-style-guide.
I would argue that using conditionals without braces introduces risk when refactoring.
I also feel that it is always more clear to use braces than to not use braces. It's for the same reason that I favor using parentheses even when the order of operations would do the same thing anyway.
For example,
x = (7 * 7) - 4;
is functionally equivalent to
x = 7 * 7 - 4;
but a novice programmer, or even an experienced one, might have to think a moment before realizing the latter would produce 45, not 21. We make a hard and fast rule for braces for the simple reason that it leaves little doubt which code should be executed. In addition, it sidesteps issues with moving code around during refactoring.
from objective-c-style-guide.
@bcapps , look at us overlapping like that! Excellent addition.
from objective-c-style-guide.
from objective-c-style-guide.
All very reasonable explanations. However, is this a style guide or an Objective-C programming book? :-) What I mean is why pick on this and not nearly everything else you could do wrong due to a fundamental misunderstanding of your stated profession?
It's easy enough to comment your way out of logic anywhere and sure, use of a poorly-worded macro would confuse even the pros for at least a moment, but I'm under the opinion that a style guide is just a style guide and not a golden rulebook of language-specific right and wrong. Sure the two relate but any document that combines subjective opinion so closely to deterministic procedure is asking for criticism.
I'm enjoying the perspective, though - I honestly don't think of a style guide as being responsible for teaching a programmer flow control. :-)
from objective-c-style-guide.
The macro justification here is wrong. Multi-statement macros that are written like that are unequivocally incorrect, and can cause problems in other use-cases too. It is not an appropriate justification for requiring braces, it is merely a justification for requiring that macros be written correctly.
Requiring braces when a new line is involved is eminently reasonable, e.g.
if (foo)
bar;
There are a number of possible justifications for requiring the braces. But they don't apply to the single-line variant
if (foo) bar;
There's no risk of introducing errors during refactoring or moving code, or incorrect indentation causing issues, and no risk of "goto fail".
That said, single-line if conditions should be used sparingly. They can increase code legibility, but they can also decrease it. But the only good reason to ban it is "because we don't want to make subjective code legibility calls", although the style guide already contains other rules that require code legibility calls (such as the one on the ternary operator).
from objective-c-style-guide.
I disagree that there's no risk of introducing errors. I would say it's quite high relatively speaking. A single line if() often becomes a multiline one and I don't want anyone to have to remember to retroactively add braces.
from objective-c-style-guide.
I disagree that there's no risk of introducing errors. I would say it's quite high relatively speaking
I agree with @paulbruneau here. I think the small benefit of concision is not worth the larger cost of having more than one way to do things and introducing subjective judgements into this part of the guide.
from objective-c-style-guide.
Related Issues (20)
- "command + z "does not work
- Execute HOT 2
- Fix broken links HOT 2
- hello
- Any plans on a swift style guide? HOT 2
- Request Create README_id-ID.md HOT 1
- let me try it
- Apple objetive C documet link don't work HOT 2
- Long time no see HOT 1
- Account has been flagged HOT 1
- printing prime numbers in N range without using function in python HOT 2
- Constants can be changed? HOT 1
- test
- test issue HOT 1
- test issue HOT 1
- obj-©
- how to convert string to Boolean?
- Ik
- Switch case
- Archive this repository HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from objective-c-style-guide.