There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
fred rosenberger wrote:... you should always use curly braces when writing your If-statements, even if not strictly necessary.
As Apple found out.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
J. Kevin Robbins wrote:The programmer who wrote that code should be demoted to burger flipper.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Life is full of choices. Sometimes you make the good ones, and sometimes you have to kill all the witnesses.
Mike Simmons wrote:Well, with auto-formatting this would have been a non-issue anyway - the indentation would have been corrected to expose the bug. To the extent it wasn't already obvious to anyone bothering to look at it anyway - the two identical gotos right next to each other seem like a huge red flag to me. But someone still has to look at it and engage a brain cell or two to realize there's a problem.
I don't really think the coding style, IDE, or even the gotos, are the main issue here though. The lack of testing is. Both in terms of unit tests and QA. I'm with Scott on that one.
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Ryan McGuire wrote:Then again, if you use Python, where the indentation matters, this would have been a non issue.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Anayonkar Shivalkar wrote:Is it copyright infringement, or Apple has released this code to public?
There are three kinds of actuaries: those who can count, and those who can't.
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Winston Gutkowski wrote:I probably shouldn't say this, but I generally don't write braces for single line sub-blocks on if statements (at the risk of getting flamed, I find unnecessary braces on them "fussy" and "noisy"); but I do indent my code. ALWAYS.
Stephan van Hulst wrote:I write so many single line if/for/while statements that my formatting options for these statements are set to "eliminate", rather than "generate".
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:I probably shouldn't say this, but I generally don't write braces for single line sub-blocks on if statements (at the risk of getting flamed, I find unnecessary braces on them "fussy" and "noisy");
but I do indent my code. ALWAYS. It just doesn't feel right if I don't, and it's one of the first things I set up when I'm working with an IDE - and I use Ctrl+Shift+F (Eclipse) constantly.
Stephan van Hulst wrote:I personally consider empty loops to be a code smell. I have empty statements set as an error. If there is a nested increment in the loop header, I tend to move it to the body, even if that makes the code more verbose.
Junilu Lacar wrote:Wouldn't you need to have the loop condition as (i < myArray.length && someCondition(myArray[i])) to account for the case where all elements satisfy the condition?
Anyway, I would lean towards refactoring this with Extract Method
Ryan McGuire wrote:
Junilu Lacar wrote:Wouldn't you need to have the loop condition as (i < myArray.length && someCondition(myArray[i])) to account for the case where all elements satisfy the condition?
In my hypothetical situation there was always going to be an non-conforming element, before the end of the array. But yes, putting int he explicit check is good idea anyways.
No more Blub for me, thank you, Vicar.
chris webster wrote:Of course, we still haven't addressed the thorny issue of whether to place the braces on the same line or not....
Junilu Lacar wrote:
For the loop breakers out there, I would remind you that the for-statement is defined as:
for (initialization; termination; increment) {
statement(s)
}
So if you're terminating the loop from the body, aren't you actually "working around" the idiom rather than with it? I prefer to actually do something with the current element in the loop body besides just checking it for the loop termination condition.
Junilu Lacar wrote:
chris webster wrote:Of course, we still haven't addressed the thorny issue of whether to place the braces on the same line or not....
I smell a style war brewing...
For the loop breakers out there, I would remind you that the for-statement is defined as:
for (initialization; termination; increment) {
statement(s)
}
So if you're terminating the loop from the body, aren't you actually "working around" the idiom rather than with it? I prefer to actually do something with the current element in the loop body besides just checking it for the loop termination condition.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Matthew Brown wrote:Though playing with functional languages is making me think I don't want to use a loop at all - a nice higher-order find function with a lambda expression for the termination condition will do me fine .
Jelle Klap wrote:Clearity and readability beats out demonstrating "cleverness" by not adding braces where they aren't strictly necessary.