You can, but you're not required to and a unit test will never catch all cases, at least for larger projects. Still I get the cleanliness and convenience of the syntax, but it's less strict, so I would hesitate to call it far superior, that's all. I personally prefer the end statements in Ruby for that reason.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Coding Style
- Thread starter butcher
- Start date
- Sort by reaction score
You can, but you're not required to and a unit test will never catch all cases, at least for larger projects. Still I get the cleanliness and convenience of the syntax, but it's less strict, so I would hesitate to call it far superior, that's all. I personally prefer the end statements in Ruby for that reason.
For short lines, I prefer bracketed one line if statements:
if (foo > 0) { bar(); }
Fits more code context in an 80x24 terminal, or landscape iPhone app.
You don't need the brackets. You only need the brackets if there is more than one statement. Most programmers would type:
if(foo < 0)
bar();
Most programmers wouldn't type that because like I said, that's a bug waiting to happen. All it takes is someone wanting to add additional logic when foo < 0 to not notice there aren't brackets, then you have:
Code:
if (foo < 0)
bar();
asdf();Looks innocent enough, but asdf() is going to be executed regardless of the outcome of the if statement.
If I checked in code at work with a brackletless if statement on two lines, I'd get a stern talking to by my boss and rightfully so.
Even if not needed according to the C language definition, it lack consistency not to use them. So I do, even in one-liners. Reduces the likelihood of future stupid editing bugs.
You actually wouldn't type it that way because the auto-indenting feature of your IDE would only indent the bar() function and you would see what was happening. Presumably you would catch the error in testing and debugging the code. I'm an old man and In my many years of programming I've never seen the error you describe, although it's theoretically possible that some first day learning-to-program amateur could make such a mistake. As far as trying to prevent stupid mistakes, forget it. Stupidity is hereditary and hence, incurable. Don't hire stupid people to program. Trying to prevent stupidity is a fool's errand.
For a real world example, look up the goto fail bug in Apple's SecureTransport this winter.
goto isn't used much in modern C. For example I can't remember seeing it in the code examples in Apple developer documentation. I can't remember ever using it when programming in C but I did use such statements in primitive languages like RPN. A friend of mine who works at the lab in Princeton showed me a thesis that proved that you never need to use a goto statement and that it could be eliminated from the language.
The problem wasn't the goto, but the double statement after an if clause without braces. Goto is quite common for error handling in C, in a cleanup and bail scenario.
http://c.learncodethehardway.org/book/ex20.html
http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/
Last edited:
The "goto fail" bug doesn't depend on goto, per se. Here's the code:
http://en.wikipedia.org/wiki/Unreachable_code#Examples
If this had been written with breaks or returns, the bug would still exist. A set of nested if's would NOT have exhibited the same bug, but if there are more than a half-dozen nesting levels, the code becomes so hard to follow there could be other bugs sneaking in.
One thing we can tell from this "goto fail" bug is that the code wasn't being compiled with "unreachable code" warnings, and/or that warnings weren't considered errors. That says more about their production process than a argument about the theoretical need for goto. It probably also says something about the limits of their test environment (test coverage).
Personally, I've been doing it that way for decades (when it doesn't violate a coding convention) and never actually had any problems.
I think the importance of this stuff in regard to coding errors is blown out of proportion and misplaced.
There isn't any code formatting conventions that will stop you from making stupid coding mistakes. Code formatting conventions are best used to promote readability NOT to prevent stupid coding typos. And there are tools much better suited to that... lints and other static code analysis and unit tests.
Readability is important, though. When working on code that others may view I have no problem with whatever coding convention.
The only thing I have never been able to get used to is where the braces are indented, like:
Code:
if (something)
{
blah();
foo();
}I suppose I would eventually get used to it, but so far whenever I have to read code like this it drives me up the wall.
True. Even if they had a mandatory policy of using curly braces - if someone missed a non-conditional jump, they could just as easily miss a if statement without braces. Hence the importance of peer-reviewed code and unit testing. Or, as you say, unreachable code warnings. You'll never be 100% safe from developer error, but you can make it a lot more difficult to fail.
Now we are throwing in if/else clauses. Here's my general rule for if/else. Try not to use them. Yep, if I feel the urge to write if/else I immediately change it to a switch statement. Why? It seems if/else statements continue to evolve as your code grows smarter. I always seem to go back and change out the multiple levels of if/else into a switch statement anyway, so I just make it a general rule, if/else = switch ( well, almost everytime ). There's always the case where a if/else statement condition cannot be simplified into a switch. I'm rambling, so sorry.
PS. if I MUST use an if/else I stick to ArtOfWar's recommendation. Consistency is the key, as already stated. We've all seen probably thousands (millions) of lines of bad code, if they are consistent we can handle it. If they switch back and forth, it kills my brain and I want to jab someone's eyes out.
PS. if I MUST use an if/else I stick to ArtOfWar's recommendation. Consistency is the key, as already stated. We've all seen probably thousands (millions) of lines of bad code, if they are consistent we can handle it. If they switch back and forth, it kills my brain and I want to jab someone's eyes out.
I agree with that, at least if there's more than a few else, but switch statements in C are restricted to integer types.
Last edited:
All humans are stupid. All make errors. Even Knuth gave away a few dollar bills. Therefore, there would be no one to hire without expecting some stupidity. Thus the need of ways to mitigate stupidity if you want anybody to do anything.
not everyone has the luxury of working in an IDE... I remember (nightmare) working in several hundred/thousand line long perl scripts through a remote ssh terminal session on solaris, with nothing but vi (vim no available) and a few unix commands. fun times. not.
I guess in the end the user/developer needs to be aware of what he/she is working with and accept/adapt to the advantages or shortcomings that environment leverages.
Try a million lines of C and Fortran on HP-UX on PA-RISC via Telnet (later SSH) using vi. Eventually we ported to Linux on x86 and got vim, but you learned to operate vi-only.
-Lee
well obviously my life didn't suck as much as yours did
but at the time this was acceptable, today you can pull your remote files in to textwrangler or any other editor of choice and work on it without any lag.
If you are using code and are trying to merge back your changes, it's a good idea to use the same brace style and indentation style as the original. Also, many projects have code style guidelines that they will reject if it isn't the proper styles.