Yep, they are the same exact thing, Casey did mention that it was just the way he was used to writing it, so there is nothing special about it. (I believe he said it during the intro to C week, but don't quote me on that).
Same thing. Some styles use the parentheses, some don't, but as long as it's consistent it makes no difference. I personally don't really like that style, it makes it look like return was a function which it is not. That's also why I put an space between the "if", "for" or "while" and the parenthesis.
But in the end it doesn't matter.
But in the end it doesn't matter.
I've found that coding conventions are one thing that no two random C programmer ever agrees on. Some languages solve this by defining a convention for the whole language, but as you'll find, it's very easy to write "legal" python code that still breaks a lot of conventions.
I've actually seen some official coding conventions that demand that indent is three spaces, which sounds like one side asking for two and the other four, and someone just deciding to make everybody equally unhappy..
Personally I follow what astyle calls ansi/allman/bsd style (more or less). But in the end, "match the style used in the source code" is the coding convention to follow.
I've actually seen some official coding conventions that demand that indent is three spaces, which sounds like one side asking for two and the other four, and someone just deciding to make everybody equally unhappy..
Personally I follow what astyle calls ansi/allman/bsd style (more or less). But in the end, "match the style used in the source code" is the coding convention to follow.
Yep, there's nothing special about return(0). Or return((0)) for that matter :) It's free to add parentheses there, but none of them are necessary - at least I can't think of a time when they would be necessary!
In theory, I suppose they could catch a bug of the following form:
I believe that would go ahead and give you an error, whereas if it didn't have the outer parentheses, it would compile fine and Thing2 would just never get called (silently).
But, I don't think I've ever had such a bug, so I don't see much profit in trying to catch it! And any compiler that has even rudimentary "unreachable code" warnings will work AOK.
- Casey
In theory, I suppose they could catch a bug of the following form:
1 2 3 | #define DoBothThings(x) Thing1(x); Thing2(x) ... return(DoBothThings(4)); |
I believe that would go ahead and give you an error, whereas if it didn't have the outer parentheses, it would compile fine and Thing2 would just never get called (silently).
But, I don't think I've ever had such a bug, so I don't see much profit in trying to catch it! And any compiler that has even rudimentary "unreachable code" warnings will work AOK.
- Casey