6 ms·

PSA: Always put brackets after your conditionals (for languages where you can). You never know when a one-line conditional will become a ten-line, and you can

by habosa 13y ago

PSA: Always put brackets after your conditionals (for languages where you can). You never know when a one-line conditional will become a ten-line, and you can get this sort of bug. It's not worth the two saved keystrokes now to have the NSA in your data later. I think the most readable code has no shortcuts and no tricks. I'll take unambiguous over concise or 'beautiful' any day.

usefulcat 13y ago
Well, yeah. But that kind of misses the point--that it would be far better if the design of the language were such that this kind of bug could not have occurred.
- habosa 13y ago
  Sure but you could just as easily add this as a compiler flag to any language. For example, I think gofmt will auto-brace your conditionals and other such things. I'm all for interesting language design but this isn't a very powerful example.
  - usefulcat 13y ago
    Adding a compiler flag after the fact does nothing to change the volumes of code that either were written before it existed or without regard for it. Also, especially in the case of C++, have fun using that feature while including any third party headers that don't adhere to that convention. From a language design perspective, part of the reason this is such a good example is precisely because there is so little to be gained by allowing the braces to be optional.
eternalban 13y ago
Anyone who has ventured into software from an engineering discipline takes it for granted that redundancy is necessary for reliable and robust systems. Another aspect of the engineering mindset that is relevant is the acceptance of burden of rigor in service of the end user. In ('haute couture') software, the matter is up-ended. It is the 'comfort' of the developer that is a key consideration and not the reliability of the product. They don't wish to be "bored" with "boring" "boiler plate", etc. I think the problem boils down to this: given the infancy of this field and the (still) primitive tooling available to support the mind-work, the field requires and attracts high percentile minds who are then tasked with building (again and again) what is in most cases glorified book keeping or plumbing systems. Naturally an outlet is required for self expression (which is a very basic need for high power minds) and that increasingly translates to need for 'bling' (thus the periodic migrations from the last "cool" stack to the new thing), and aesthetic 'elegance'.
- mattgreenrocks 13y ago
  There is a palpable disdain for any concept of discipline or engineering in this age of Lean. YAGNI, they cry! Just ship! To feed this culture of shipping-before-thinking, we're inundated with an endless stream of magical frameworks that will do nearly everything for us if we just trust them completely.
  - wpietri 13y ago
    I agree with a chunk of this, especially the dislike for magical frameworks, but you're wrong to pick on Lean and YAGNI there. YAGNI (You Ain't Gonna Need It) in specific comes from Extreme Programming, which is big on engineering discipline. E.g., its inclusion of Test-Driven Development and Pair Programming as practices. YAGNI isn't used there to reduce quality; it's used to reduce product complexity by only building features that are demonstrably necessary. Which, in my experience, helps with quality. As to Lean, it's rooted in Lean Manufacturing, which comes from Toyota. An engineering-driven company, they used Lean techniques to reach quality levels way higher than competing car manufacturers, which gave them an enormous competitive advantage. If people are using those terms to justify shipping crap, then they're doing it wrong.
    - copergi 13y ago
      >YAGNI (You Ain't Gonna Need It) in specific comes from Extreme Programming, which is big on engineering discipline How is extreme programming even remotely related to engineering discipline? It is a bunch of randomly tossed together practices with no proven value or efficacy, pitched by people who were incapable of doing the job themselves, to teach other people how to do the job. YAGNI is controversial at best, and often creates far bigger problems that what it was intended to solve. And that is when it is combined with the rest of the rituals it was intended to work with. On its own it isn't even recommended by the people who made it up. >As to Lean, it's rooted in Lean Manufacturing The name is anyways, but that seems to be about it. Lean manufacturing was about eliminating things that don't add value for the customer. The lean fad in software development seems to be most often applied by people who can't even tell you who their customer might be, much less what adds value for them. >If people are using those terms to justify shipping crap, then they're doing it wrong If processes rarely work and any failure is dismissed as "you're doing it wrong", then your processes are worthless. This is "any failure can be attributed to you not following our religion correctly" thing is one of the major things that killed XP.
hcarvalhoalves 13y ago
> Always put brackets after your conditionals (for languages where you can) That's the point. The programmer shouldn't have to remember to write code the Right Way, rather the language should be designed to avoid these ambiguities.
- emeraldd 13y ago
  If you're using a language more complex than HQ9+ to accomplish your goal, there will always be a Wrong Way to do something and someone is going to find it. Granted, you can attempt to limit the number of Wrong Ways, but it will never be possible to eliminate them.
  - SapphireSun 13y ago
    Consider problems as a Poisson distribution. If you eliminate problems, there will be infinitely many more, but they will be rarer and increase the overall stability of the system. Once you eliminate so many errors that the mean time between failures is greater than (say) 100 years, that's basically equivalent to having a bug free system since the system will almost certainly be retired before then.
  - sitkack 13y ago
    That is a thought terminating statement. Using your logic it is alright to move towards a "more wrong" language for a task?
jobu 13y ago
It's amazing how following good coding standards can make bugs go away. If anyone disagrees, I would suggest reading Joel Spolsky's article "Making Wrong Code Look Wrong": http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html That article changed my perspective on coding standards. To your PSA, I would like to add: Never use the '!' operator at the beginning of a conditional. It's too easy to miss when reviewing or changing code, especially next to certain characters: if(!llama) { ... } This is a tiny bit more text, and so much safer for maintainers: if(llama == false) { ... }
- nawitus 13y ago
  I think the '!' is easy to spot when using a good monospaced font.
- wting 13y ago
  Now you have the bug occur if someone forgets an equal since this is always true: if (llama = false) So use Yoda conditionals instead: if (false == llama) Is that really an improvement over the original? As I've stated in my sibling reply, you are decreasing human readability for machine readability.
  - wtetzner 13y ago
    Maybe if (llama != true) instead? Or maybe you just use a not function: if (not(llama))
  - jobu 13y ago
    I have seen code that uses the Yoda style, but I think it's a bit overkill. Any C/C++ compiler I've used in the last several years will complain if you do an assignment in a conditional. (Unfortunately I've also seen projects that spew out a slew of compiler warnings under normal circumstances, so YMMV.)
- mikestew 13y ago
  I've taken to trying to make the ! stand out more: if( ! llama) { ... } I don't know that it's an improvement, and my personal jury is still out, but I currently hold that it's better than the risk of the single equals bug that another reply points out, or the Yoda conditional that is the suggested replacement.
wting 13y ago
> I think the most readable code has no shortcuts and no tricks. I'll take unambiguous over concise or 'beautiful' any day. Ambiguity and conciseness are orthogonal concepts. Mathematics and formal proofs are very unambiguous, yet they are concise. On the other hand assembly code is unambiguous yet very verbose. Code has to convey two things: 1. "what should be done" to humans 2. "how to do it" to machines Striking a balance between these two is difficult since it depends on each individual coder and the programming language. That's why there are so many syntax bike shedding wars because what's readable to one isn't necessarily readable to another.
- JackMorgan 13y ago
  Indeed, it is an easy mistake to claim that unambiguous code has to be verbose when all you've ever done is read and write verbose code. Mathematical proofs are hard to read, and take time to master, but are rewarding in the amount of information that can be conveyed in a short amount of information.
- tel 13y ago
  I disagree. Mathematics is often very ambiguous and formal proofs are often very long. The trick with informal mathematics is that the author and the reader (a) share a large amount of background and (b) tacitly assume that the text is talking about something interesting. So, given those things, you can usually resolve ambiguity by assuming that the proof is referring to the interesting part at hand instead of some boring detail. The downside to that is the ambiguity sometimes causes bugs. Formal proofs can be very long. It's an open problem today as to how to compress and decomplect them. It's extremely similar to the situation with programming. I'm not sure that I intend to refute your argument at its core—clarity does not imply great verbosity in my mind—but instead to color your example a little more. As a perhaps more specific, powerful example one could consider "Proofs by the Book" of Erdös-style wonderfully short proofs. These usually demonstrate the interesting characteristic of having very high "compression".
  - auvrw 13y ago
    i half disagree. even informal proofs are often very long, but while they may omit some steps omitted, i wouldn't say they're ambiguous. it's just that writing something for a human who can (and in fact will find it easier to) fill in some blanks themselves is different for writing something for a machine, which only understands "how to do" kinds of descriptions. also, a tangent about Erdos: Erdos was really good at posing problems. if his proofs are concise, it could have something to do with the problems he chose to work on. i'm not saying there's no book, i'm just saying that the most perfect, concise proof of some facts might still turn out to be very long.
Periodic 13y ago
I worked at a company a ways back that had a very strict rule about always putting braces on conditionals. This was because at one point an engineer changed a one-line conditional to a two-line conditional and forgot his braces. It was a fairly minor condition, and it slipped through testing. It ended up being responsible for a very quick $5M in lost revenue before it was caught and the code was rolled back. Of course there are some better practices that would have caught it, but it was an easy mistake to make and an easy mistake to miss. Another one I've come to enjoy is Java's insistence that I only provide booleans to my conditionals. It is a bit onerous to write "== NULL" a lot, but there have also been many times in C I accidentally forgot that the function I was calling did not return a boolean and so my test didn't do what I thought it would. For example, memcmp is not a true/false function but a negative/zero/positive function and so if you do not check "== 0" you can easily invert your logic.

by habosa 13y ago

usefulcat 13y ago

Well, yeah. But that kind of misses the point--that it would be far better if the design of the language were such that this kind of bug could not have occurred.

habosa 13y ago
Sure but you could just as easily add this as a compiler flag to any language. For example, I think gofmt will auto-brace your conditionals and other such things. I'm all for interesting language design but this isn't a very powerful example.
- usefulcat 13y ago
  Adding a compiler flag after the fact does nothing to change the volumes of code that either were written before it existed or without regard for it. Also, especially in the case of C++, have fun using that feature while including any third party headers that don't adhere to that convention. From a language design perspective, part of the reason this is such a good example is precisely because there is so little to be gained by allowing the braces to be optional.

eternalban 13y ago

Anyone who has ventured into software from an engineering discipline takes it for granted that redundancy is necessary for reliable and robust systems. Another aspect of the engineering mindset that is relevant is the acceptance of burden of rigor in service of the end user. In ('haute couture') software, the matter is up-ended. It is the 'comfort' of the developer that is a key consideration and not the reliability of the product. They don't wish to be "bored" with "boring" "boiler plate", etc. I think the problem boils down to this: given the infancy of this field and the (still) primitive tooling available to support the mind-work, the field requires and attracts high percentile minds who are then tasked with building (again and again) what is in most cases glorified book keeping or plumbing systems. Naturally an outlet is required for self expression (which is a very basic need for high power minds) and that increasingly translates to need for 'bling' (thus the periodic migrations from the last "cool" stack to the new thing), and aesthetic 'elegance'.

mattgreenrocks 13y ago
There is a palpable disdain for any concept of discipline or engineering in this age of Lean. YAGNI, they cry! Just ship! To feed this culture of shipping-before-thinking, we're inundated with an endless stream of magical frameworks that will do nearly everything for us if we just trust them completely.
- wpietri 13y ago
  I agree with a chunk of this, especially the dislike for magical frameworks, but you're wrong to pick on Lean and YAGNI there. YAGNI (You Ain't Gonna Need It) in specific comes from Extreme Programming, which is big on engineering discipline. E.g., its inclusion of Test-Driven Development and Pair Programming as practices. YAGNI isn't used there to reduce quality; it's used to reduce product complexity by only building features that are demonstrably necessary. Which, in my experience, helps with quality. As to Lean, it's rooted in Lean Manufacturing, which comes from Toyota. An engineering-driven company, they used Lean techniques to reach quality levels way higher than competing car manufacturers, which gave them an enormous competitive advantage. If people are using those terms to justify shipping crap, then they're doing it wrong.
  - copergi 13y ago
    >YAGNI (You Ain't Gonna Need It) in specific comes from Extreme Programming, which is big on engineering discipline How is extreme programming even remotely related to engineering discipline? It is a bunch of randomly tossed together practices with no proven value or efficacy, pitched by people who were incapable of doing the job themselves, to teach other people how to do the job. YAGNI is controversial at best, and often creates far bigger problems that what it was intended to solve. And that is when it is combined with the rest of the rituals it was intended to work with. On its own it isn't even recommended by the people who made it up. >As to Lean, it's rooted in Lean Manufacturing The name is anyways, but that seems to be about it. Lean manufacturing was about eliminating things that don't add value for the customer. The lean fad in software development seems to be most often applied by people who can't even tell you who their customer might be, much less what adds value for them. >If people are using those terms to justify shipping crap, then they're doing it wrong If processes rarely work and any failure is dismissed as "you're doing it wrong", then your processes are worthless. This is "any failure can be attributed to you not following our religion correctly" thing is one of the major things that killed XP.

hcarvalhoalves 13y ago

> Always put brackets after your conditionals (for languages where you can) That's the point. The programmer shouldn't have to remember to write code the Right Way, rather the language should be designed to avoid these ambiguities.

emeraldd 13y ago
If you're using a language more complex than HQ9+ to accomplish your goal, there will always be a Wrong Way to do something and someone is going to find it. Granted, you can attempt to limit the number of Wrong Ways, but it will never be possible to eliminate them.
- SapphireSun 13y ago
  Consider problems as a Poisson distribution. If you eliminate problems, there will be infinitely many more, but they will be rarer and increase the overall stability of the system. Once you eliminate so many errors that the mean time between failures is greater than (say) 100 years, that's basically equivalent to having a bug free system since the system will almost certainly be retired before then.
- sitkack 13y ago
  That is a thought terminating statement. Using your logic it is alright to move towards a "more wrong" language for a task?

jobu 13y ago

It's amazing how following good coding standards can make bugs go away. If anyone disagrees, I would suggest reading Joel Spolsky's article "Making Wrong Code Look Wrong": http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html That article changed my perspective on coding standards. To your PSA, I would like to add: Never use the '!' operator at the beginning of a conditional. It's too easy to miss when reviewing or changing code, especially next to certain characters: if(!llama) { ... } This is a tiny bit more text, and so much safer for maintainers: if(llama == false) { ... }

nawitus 13y ago
I think the '!' is easy to spot when using a good monospaced font.
wting 13y ago
Now you have the bug occur if someone forgets an equal since this is always true: if (llama = false) So use Yoda conditionals instead: if (false == llama) Is that really an improvement over the original? As I've stated in my sibling reply, you are decreasing human readability for machine readability.
- wtetzner 13y ago
  Maybe if (llama != true) instead? Or maybe you just use a not function: if (not(llama))
- jobu 13y ago
  I have seen code that uses the Yoda style, but I think it's a bit overkill. Any C/C++ compiler I've used in the last several years will complain if you do an assignment in a conditional. (Unfortunately I've also seen projects that spew out a slew of compiler warnings under normal circumstances, so YMMV.)
mikestew 13y ago
I've taken to trying to make the ! stand out more: if( ! llama) { ... } I don't know that it's an improvement, and my personal jury is still out, but I currently hold that it's better than the risk of the single equals bug that another reply points out, or the Yoda conditional that is the suggested replacement.

wting 13y ago

> I think the most readable code has no shortcuts and no tricks. I'll take unambiguous over concise or 'beautiful' any day. Ambiguity and conciseness are orthogonal concepts. Mathematics and formal proofs are very unambiguous, yet they are concise. On the other hand assembly code is unambiguous yet very verbose. Code has to convey two things: 1. "what should be done" to humans 2. "how to do it" to machines Striking a balance between these two is difficult since it depends on each individual coder and the programming language. That's why there are so many syntax bike shedding wars because what's readable to one isn't necessarily readable to another.

JackMorgan 13y ago
Indeed, it is an easy mistake to claim that unambiguous code has to be verbose when all you've ever done is read and write verbose code. Mathematical proofs are hard to read, and take time to master, but are rewarding in the amount of information that can be conveyed in a short amount of information.
tel 13y ago
I disagree. Mathematics is often very ambiguous and formal proofs are often very long. The trick with informal mathematics is that the author and the reader (a) share a large amount of background and (b) tacitly assume that the text is talking about something interesting. So, given those things, you can usually resolve ambiguity by assuming that the proof is referring to the interesting part at hand instead of some boring detail. The downside to that is the ambiguity sometimes causes bugs. Formal proofs can be very long. It's an open problem today as to how to compress and decomplect them. It's extremely similar to the situation with programming. I'm not sure that I intend to refute your argument at its core—clarity does not imply great verbosity in my mind—but instead to color your example a little more. As a perhaps more specific, powerful example one could consider "Proofs by the Book" of Erdös-style wonderfully short proofs. These usually demonstrate the interesting characteristic of having very high "compression".
- auvrw 13y ago
  i half disagree. even informal proofs are often very long, but while they may omit some steps omitted, i wouldn't say they're ambiguous. it's just that writing something for a human who can (and in fact will find it easier to) fill in some blanks themselves is different for writing something for a machine, which only understands "how to do" kinds of descriptions. also, a tangent about Erdos: Erdos was really good at posing problems. if his proofs are concise, it could have something to do with the problems he chose to work on. i'm not saying there's no book, i'm just saying that the most perfect, concise proof of some facts might still turn out to be very long.

Periodic 13y ago

I worked at a company a ways back that had a very strict rule about always putting braces on conditionals. This was because at one point an engineer changed a one-line conditional to a two-line conditional and forgot his braces. It was a fairly minor condition, and it slipped through testing. It ended up being responsible for a very quick $5M in lost revenue before it was caught and the code was rolled back. Of course there are some better practices that would have caught it, but it was an easy mistake to make and an easy mistake to miss. Another one I've come to enjoy is Java's insistence that I only provide booleans to my conditionals. It is a bit onerous to write "== NULL" a lot, but there have also been many times in C I accidentally forgot that the function I was calling did not return a boolean and so my test didn't do what I thought it would. For example, memcmp is not a true/false function but a negative/zero/positive function and so if you do not check "== 0" you can easily invert your logic.