12 common mistakes done by programmers
Most often, software developers seem locked into certain failure modes that can't be avoided and such is the frequency with which they fall prey to a particular poor programming practice. Peter Wayner of Computerworld writes about twelve most common programming mistakes, each of which is accompanied by its opposing pair. Below are the twelve programming pitfalls developers should stay away from.
Playing it fast and loose
Failing to prop up the basics is the easiest way to make errors in coding. There are a lot of small places where a developer may make a mistake which causes software to fail. And the worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. There have been improvements in syntax in programming languages. For instance, the latest version of Java tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. But such syntax improvements can only prevent code from crashing. They don't eliminate the root of the problem: the proliferation of null values due to fast and loose programming.
Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Relentless devotion to detail can even lock up software if the obsessive checking requires communicating with a distant website over the network. Here, the challenge is to design the layers of code to check the data when it first appears, which is much easier said than done.
Not simplifying control
Not simplifying control over tasks in their code may invite disaster for developers. The software assumes that if someone creates an object of type Name with two fields first and last, then it should immediately create a database table called Name with two columns, first and last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.
Delegating too much to frameworks
Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code. The rules are, while quite reasonable, not entirely trivial. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge.
Trusting the client
Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.
Not trusting the client enough
Sometimes too much security can lead paradoxically to gaping holes. Because of this, many Web developers are looking to reduce security as much as possible, not only to make it easy for people to engage with their products but also to save them the trouble of defending more than the minimum amount of data necessary to set up an account.
Relying too heavily on magic boxes
Many programmers assume they can link in the encryption library, push a button, and have iron-clad security. But many of these magic algorithms have subtle weaknesses, and avoiding these weaknesses requires learning more than what's in the Quick Start section of the manual.
Reinventing the wheel
Then again, writing your own libraries just because you think you know a better way to code can come back to haunt you. But grow-your-own cryptography is a welcome sight to attackers. Many libraries don't need to be perfect, so grabbing a magic box is more likely to be better than the code you write yourself.
Opening up too much to the user
Placing the onus on users to customize functionality they do not fully understand can invite disaster in the form of inadvertent security holes and privacy violations. When making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software.
Playing it fast and loose
Failing to prop up the basics is the easiest way to make errors in coding. There are a lot of small places where a developer may make a mistake which causes software to fail. And the worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. There have been improvements in syntax in programming languages. For instance, the latest version of Java tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. But such syntax improvements can only prevent code from crashing. They don't eliminate the root of the problem: the proliferation of null values due to fast and loose programming.
Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Relentless devotion to detail can even lock up software if the obsessive checking requires communicating with a distant website over the network. Here, the challenge is to design the layers of code to check the data when it first appears, which is much easier said than done.
Not simplifying control
Not simplifying control over tasks in their code may invite disaster for developers. The software assumes that if someone creates an object of type Name with two fields first and last, then it should immediately create a database table called Name with two columns, first and last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.
Delegating too much to frameworks
Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code. The rules are, while quite reasonable, not entirely trivial. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge.
Trusting the client
Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.
Not trusting the client enough
Sometimes too much security can lead paradoxically to gaping holes. Because of this, many Web developers are looking to reduce security as much as possible, not only to make it easy for people to engage with their products but also to save them the trouble of defending more than the minimum amount of data necessary to set up an account.
Relying too heavily on magic boxes
Many programmers assume they can link in the encryption library, push a button, and have iron-clad security. But many of these magic algorithms have subtle weaknesses, and avoiding these weaknesses requires learning more than what's in the Quick Start section of the manual.
Reinventing the wheel
Then again, writing your own libraries just because you think you know a better way to code can come back to haunt you. But grow-your-own cryptography is a welcome sight to attackers. Many libraries don't need to be perfect, so grabbing a magic box is more likely to be better than the code you write yourself.
Opening up too much to the user
Placing the onus on users to customize functionality they do not fully understand can invite disaster in the form of inadvertent security holes and privacy violations. When making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software.
Comments
Post a Comment