Why Bother with Standards

• Good programming is as much art as science.
  There's a difference between a coder and a sofware engineer.
  Any coder can eventually write a program that produces the desired output. A professional software engineer does more than just write a program. He writes a program that is easily understood by others, reusable and easily modified. He uses simple, straightforward and "elegant" coding techniques and algorithms.
• 80% of a programmer's work is modifying existing code.
• Programmers come and go frequently.
• Getting the right output is overrated.
  Just getting the right output for your each of your projects won't get you an 'A' in this course.
• The following quote from "The Practice of Programming" (Brian Kernighan/Rob Pike, page 27/28) sums the need for good programming style.

  "...the main concerns of programming style: descriptive names, clarity in expressions, straightforward control flow, readability of code and comments, and the importance of consistent use of conventions and idioms in achieving all of these. It's hard to argue that these are bad things.

  But why worry about style? Who cares if it works? Doesn't it take way too much time to make it look pretty? Aren't the rules arbitrary anyway?

  The answer is that well-written code is easier to read and to understand, almost surely has fewer errors, and is likely to be smaller code than code that has been carelessly tossed together and never polished. In the rush to get programs out the door to meet some deadline, it's easy to push style aside, to worry about it later. This can be a costly decision. Some of the examples in this chapter show what can go wrong if there isn't enough attention to good style. Sloppy code is bad code -- not just awkward and hard to read, but often broken.

  The key observation is that good style should be a matter of habit. If you think about style as you write code originally, and if you take the time to revise and improve it, you will develop good habits. Once they become automatic, your subconscious will take care of many of the details for you, and even the code you produce under pressure will be better."

• Well-written programs will likely have fewer bugs, and bugs are easier to find.
  • This will save you countless headaches when trying to debug your programs
  • Bug-free programs are more secure.
    • Security is a major concern these days. Privacy of data has serious legal implications in many programming applications today. For example, releasing credit card numbers, social security numbers, or health care information to unauthorized people can result in major lawsuits against your company. Currently, there are not any legal liabilities held against individual programmers, but your job may be in jeopardy in a serious incident.
    • How do hackers and virus writers succeed? First, they must find a vulnerability to exploit. That is, they must find a bug (a logical error, not a compile error) in some piece of code. What happens to your code when it is given unexpected or invalid input? Many security vulnerabilities are based on giving unexpected or invalid input to some piece of code. Simply trying to account for as many unexpected inputs as possible is an easy and important part of developing secure code on a larger scale.
    • Since large projects are composed of smaller projects, it is important to develop well-written code even in small, seemingly insignificant projects. If your small project contains bugs or logical errors, and is later incorporated into a larger project, it can easily create bugs and security vulnerabilities in the larger project.
    • Common mistakes which can easily lead to large security problems will be highlighted throughout this course. However, it is important to always consider what unexpected conditions may occur in your programs and take measures to handle them.

What if there were no standards

For even more fun like this, visit www.ioccc.org.