7 ms·

It's probably a matter of style at some level. I hate this style (from the article): if (...) { if (...) { ... } else { if (

It's probably a matter of style at some level. I hate this style (from the article): if (...) { if (...) { ... } else { if (...) { ... } else if (...) { ... } else { ... } } and prefer this: if (...) { if (...) { ... } else { if (...) { ... } else if (...) { .. } else { ... } } } The first example is confusing and hard to read. The second is clean and easy to read. As to the question of optimization, that's a different matter. Lots of tricks can be used to compress code into fewer statements on a case by case basis: if(pushbutton == 0) { led = 12; } else { led = 24; } can become led = (pushbutton == 0) ? 12 : 24; or led = (pushbutton * 12) + 12; or led = 12 * (pushbutton + 1); etc.

alexseman 14y ago
I also find the second style much more readable.
epistasis 14y ago
I find the first version easy to read, and the second confusing and hard to read. I believe this is a matter of what a person is more accustomed to, and I learned on the first form and lately have been using the first form more. For me the extra brace below the keywords makes it hard to find the phrase of interest, and the expanded vertical space also makes it more difficult to line up indentation levels. But these visual cues are flexible, and I could learn similar scanning tricks for the second form. I have worked with people that were dogmatic that one form was objectively better than another form, rather than it being a matter of local optimization in the brain; I have difficult working with these people because they tend to show similar rigidity and confusion of the subjective with the objective in other areas, and such small mindedness limits what type of engineering solutions one is able to come up with.
- nightski 14y ago
  Agreed. If I was forced to pick it would probably be the first one, but other than that I just don't care.
  - robomartin 14y ago
    Did either of you pick-up the fact that the first version is missing a curly brace? :) Hard to see. That's my point. And that's why I tend to favor the second style. I'll use any convention if required, but if given a choice I go for styles that protect me from my own dumb mistakes as much as possible.
masanqi 14y ago
I agree, the second style is infinitely more readable. It clearly shows the hierarchy. Unfortunately it seems to be rare compared to the second one, as most people seem to want to hide the opening braces or something. Maybe because they come from ugly languages without braces, like Assembly, Python, Fortran, or Ruby...
- robomartin 14y ago
  I don't know why you were downvoted. I've programmed in everything from entering hex code into a hexadecimal keypad to assembly, Forth, APL and beyond. Sure, languages can influence style. I wouldn't go as far as calling any language "ugly". There's that initial phase of exposure when one might not be comfortable with the language constructs. And yes, at that moment in time it is natural to feel that a language might be "ugly". I certainly felt that way when learning Objective-C. Once you get on the other side and you start using the language for real work things can change. I don't hate any particular language but do enjoy some more than others. Forth, APL and Lisp were a lot of fun to work with.
randallsquared 14y ago
""" can become led = (pushbutton == 0) ? 12 : 24; or led = (pushbutton * 12) + 12; or led = 12 * (pushbutton + 1); """ It might be worth pointing out that the latter two don't actually have the same result as the if/else.
- robomartin 14y ago
  How so?
  - renata 14y ago
    In C at least, pushbutton could be strictly greater than one and still be treated as true, but that would be a different result in the arithmetic versions of the statement. It could be made identical by using "!!pushbutton".
    - robomartin 14y ago
      I think you might be taking what was intended to be a simple example a little too far. That said, "pushbutton" could very well be limited to the values 0 and 1 during the keypad scanning, debouncing and decoding code. Chill bro.
  - alexatkeplar 14y ago
    Where pushbutton == 2, 36 != 24
  - bmm6o 14y ago
    If pushbutton is neither 0 nor 1.
ChuckMcM 14y ago
An early history of writing code on 24 x 80 terminals has trained me to prefer K&R style (where the bracket is on the same line as the if) over the expanded style. The goal was to have as much of the code on the screen as possible so vertical space was precious. Of course when you've got a 1080p monitor on its side you get all the vertical space you need and the open style does give you more room. I strongly avoid however converting logical semantics into arithmetic ones. The LED example where: led = (pushbutton * 12) + 12; Makes me cringe. You know that the person who wrote that assumed 'non-zero' meant it was pressed, not '1' means its pressed at some point the pushbutton is connected to bit 3 of the I/O port and the the kid was doing a byte read 'cuz it was easy' and now the value of pushbutton is 8 (which still would work on their code but not the refactored code) and led gets the value 108 and the code that takes the LED value turns on some random GPIO bit somewhere else because it can "only" get either 12 or 24 when now it can get a lot of different values. And a long escalation in manufacturing that the 'new software screws up the gizmo' turns out to be a side effect from refactoring. Been there, done that, wrote the after action report. No thanks!
- robomartin 14y ago
  Just a silly example. Real I/O code should have lots of checks and balances.
  - ChuckMcM 14y ago
    Two responses: First I understood that you were not seriously proposing this sort of I/O code, but as someone who has been around the block my share of times I know that such code both exists and is in production, almost exactly as written. The memories are like a war veteran who can't forget the trenches, I wince now and then :-). Second, my comment was that code which has a 'boolean' flow is probably boolean code, and not arithmetic code. So any refactoring that 'assumes' boolean and uses arithmetic becomes a landmine for some future coder to trip over. MUCH better to refactor the code as such into: led = (button)? 12 : 24; Than "assuming" that true is '1' and false is '0'. When reading old code I've trained my self to read the statement if (variable == 0) { // this code assumes the variable is zero } else { // this code has to work for all non-zero values } Which may not have been the programmer's intent, but it is what they wrote.
ilaksh 14y ago
I prefer this: if if else if else if else In other words, I prefer CoffeeScript. Good procedural code is factored into short functions, which would make some of the types of programs the article is alluding to easier to read. Also, object oriented programming can be a good option for reducing cyclomatic complexity in a lot of different situations where the system you are modeling lends itself to a class structure. And CoffeeScript makes this easier also.

alexseman 14y ago

I also find the second style much more readable.

epistasis 14y ago

I find the first version easy to read, and the second confusing and hard to read. I believe this is a matter of what a person is more accustomed to, and I learned on the first form and lately have been using the first form more. For me the extra brace below the keywords makes it hard to find the phrase of interest, and the expanded vertical space also makes it more difficult to line up indentation levels. But these visual cues are flexible, and I could learn similar scanning tricks for the second form. I have worked with people that were dogmatic that one form was objectively better than another form, rather than it being a matter of local optimization in the brain; I have difficult working with these people because they tend to show similar rigidity and confusion of the subjective with the objective in other areas, and such small mindedness limits what type of engineering solutions one is able to come up with.

nightski 14y ago
Agreed. If I was forced to pick it would probably be the first one, but other than that I just don't care.
- robomartin 14y ago
  Did either of you pick-up the fact that the first version is missing a curly brace? :) Hard to see. That's my point. And that's why I tend to favor the second style. I'll use any convention if required, but if given a choice I go for styles that protect me from my own dumb mistakes as much as possible.

masanqi 14y ago

I agree, the second style is infinitely more readable. It clearly shows the hierarchy. Unfortunately it seems to be rare compared to the second one, as most people seem to want to hide the opening braces or something. Maybe because they come from ugly languages without braces, like Assembly, Python, Fortran, or Ruby...

robomartin 14y ago
I don't know why you were downvoted. I've programmed in everything from entering hex code into a hexadecimal keypad to assembly, Forth, APL and beyond. Sure, languages can influence style. I wouldn't go as far as calling any language "ugly". There's that initial phase of exposure when one might not be comfortable with the language constructs. And yes, at that moment in time it is natural to feel that a language might be "ugly". I certainly felt that way when learning Objective-C. Once you get on the other side and you start using the language for real work things can change. I don't hate any particular language but do enjoy some more than others. Forth, APL and Lisp were a lot of fun to work with.

randallsquared 14y ago

""" can become led = (pushbutton == 0) ? 12 : 24; or led = (pushbutton * 12) + 12; or led = 12 * (pushbutton + 1); """ It might be worth pointing out that the latter two don't actually have the same result as the if/else.

robomartin 14y ago
How so?
- renata 14y ago
  In C at least, pushbutton could be strictly greater than one and still be treated as true, but that would be a different result in the arithmetic versions of the statement. It could be made identical by using "!!pushbutton".
  - robomartin 14y ago
    I think you might be taking what was intended to be a simple example a little too far. That said, "pushbutton" could very well be limited to the values 0 and 1 during the keypad scanning, debouncing and decoding code. Chill bro.
- alexatkeplar 14y ago
  Where pushbutton == 2, 36 != 24
- bmm6o 14y ago
  If pushbutton is neither 0 nor 1.

ChuckMcM 14y ago

An early history of writing code on 24 x 80 terminals has trained me to prefer K&R style (where the bracket is on the same line as the if) over the expanded style. The goal was to have as much of the code on the screen as possible so vertical space was precious. Of course when you've got a 1080p monitor on its side you get all the vertical space you need and the open style does give you more room. I strongly avoid however converting logical semantics into arithmetic ones. The LED example where: led = (pushbutton * 12) + 12; Makes me cringe. You know that the person who wrote that assumed 'non-zero' meant it was pressed, not '1' means its pressed at some point the pushbutton is connected to bit 3 of the I/O port and the the kid was doing a byte read 'cuz it was easy' and now the value of pushbutton is 8 (which still would work on their code but not the refactored code) and led gets the value 108 and the code that takes the LED value turns on some random GPIO bit somewhere else because it can "only" get either 12 or 24 when now it can get a lot of different values. And a long escalation in manufacturing that the 'new software screws up the gizmo' turns out to be a side effect from refactoring. Been there, done that, wrote the after action report. No thanks!

robomartin 14y ago
Just a silly example. Real I/O code should have lots of checks and balances.
- ChuckMcM 14y ago
  Two responses: First I understood that you were not seriously proposing this sort of I/O code, but as someone who has been around the block my share of times I know that such code both exists and is in production, almost exactly as written. The memories are like a war veteran who can't forget the trenches, I wince now and then :-). Second, my comment was that code which has a 'boolean' flow is probably boolean code, and not arithmetic code. So any refactoring that 'assumes' boolean and uses arithmetic becomes a landmine for some future coder to trip over. MUCH better to refactor the code as such into: led = (button)? 12 : 24; Than "assuming" that true is '1' and false is '0'. When reading old code I've trained my self to read the statement if (variable == 0) { // this code assumes the variable is zero } else { // this code has to work for all non-zero values } Which may not have been the programmer's intent, but it is what they wrote.

ilaksh 14y ago

I prefer this: if if else if else if else In other words, I prefer CoffeeScript. Good procedural code is factored into short functions, which would make some of the types of programs the article is alluding to easier to read. Also, object oriented programming can be a good option for reducing cyclomatic complexity in a lot of different situations where the system you are modeling lends itself to a class structure. And CoffeeScript makes this easier also.