Every programmer makes mistake and this is accepted globally as
unwritten truth. And most of the time developer doesn't know what
mistakes they are making. Here are my list of top mistakes to avoid.
Lack of security
There are two aspects programmers forget while coding the system.
1. Strategic aspects
Most
programmers start coding the applications with the view of implementing
the features from the default security perspective of "allowing all"
the user to access and then will start to implement security for the
elements (See Tactical aspects & suggestion on which elements to
secure).
This happens across the board. Everything from operating
systems to fat clients to web-based thin clients are constructed this
way.
My strategic suggestion is to start coding from a default
perspective of giving "deny all" access to every architectural element,
every layer, every object, every method, every variable, etc., and
construct them to be inaccessible to anything unless you expressly allow
it. This will slow down your productivity a little (at least at first).
However, once system is coded this way the delivered code and system
will be vastly more secure.
Also, another rule for programmer is
"Don't roll your own" or "Don't reinvent the wheel". Unless you are
yourself a security expert and/or cryptographer,
always use a
well-designed, well-tested, and mature security platform, framework, or
library to do the work for you. These things have spent years being
thought out, patched, updated, and examined by experts and hackers
alike. You want to gain those advantages, not dismiss them by trying to
reinvent the wheel.
Now, that's not to say you don't need to learn
anything about security. You certainly need to know enough to
understand what you're doing and make sure you're using the tools
correctly. However, if you ever find yourself about to start writing
your own cryptography algorithm, authentication system, input sanitizer,
etc, stop, take a step back, and remember this rule.
2. Tactical aspects
In
Tactical aspects, here are the common mistakes while coding security
and things which every programmer should care about while coding the
system.
- Not validating every bit of data from the client and user inputs
- Not considering filesystem permissions when working with files
- Not
thinking about the database access permissions and keeping it too wide
open for example, providing read-write access where only read is
required
- Storing sensitive data in clear text like passwords, etc
- Not enforcing the strong passwords
- Thinking the user sees the system the programmer sees it
- Assuming system will never be attacked
- Thinking its Network Admin's responsibilities to provide security to the Network and applications
- Sending the sensitive data in query strings in websites
- Not taking care of hacking techniques like cross-scripting, SQL injections, etc
- Using third party libraries hastily without validating them
- Thinking login is the only page where security is needed.
- Creating backdoors for Administrative purposes
Improper Code Formatting
Easiest
way to differentiate between experienced and inexperienced programmer
is how they format their code. Most of the programming languages
doesn't give error because of bad formatting of the code like
indentation, use of white space, etc but it makes code extremely
unmanageable if its not formatted properly. Programmers don't
understand that indenting code makes one logical structure. By
indenting (using tabs and spaces) functions, loop, conditions, etc makes
code readable and manageable not only for others but for ourselves as
well. Bad formatted code becomes error prone and difficult to debug.
Another
bad habit programmers have is to leave huge chunk of non-required
commented code. Almost everyone do this mistake thinking that we might
need this in the future. Its always good to remove the commented code
if its not required.
Improper Variable and/or Function name
Sometimes
its looks funny to us when some programmers use long function or
variable names like fileForReading, but its actually good to have long
meaningful name rather than short meaningless name. If we give
meaningful names to variables and functions then its intent becomes very
clear not only while coding for the first time but also during the
maintenance. This will result in less errors as well because using
non-meaningful name makes the probability of getting confused why this
function and/or variable is created. Worst mistake developer can make is
do the spelling mistakes while creating the variable names. It becomes
difficult to remember the misspelt variable name and in high probability
you will end up causing too many compiler errors. Its always better
each developer makes its own naming convention as per their convenience
as this will make them write the code faster and will reduce the
compiler errors as well.
Case sensitivity
Some
programming languages are case sensitive and some are not. But its
always better to use the cases (upper or lower) of the variable and
function name properly. This is also true while creating the hyperlinks
and referencing the files. Windows is case insensitive so it doesn't
matter if you use /program or /Program but it does matter in non-windows
platforms. And when you are writing platform independent code always
be careful about cases of the objects you use. Also, each programming
language comes with its own convention like Java recommends to use camel
case convention where starting letter of first word should be in
lowercase and starting letter of remaining words should be in upper
case. Java doesn't throw error if this convention is not used but it
looks odd when this is not followed.
Lack of commenting and/or overcommenting
Lack
of commenting and doing over-commenting both are crime. Everyone
should self-document their code where programmer explains the use of the
variable, function and class names, and overall architecture and
communicate the meaning of the code to other programmers and your future
self without the need for lengthy comments. Whereas, over-commenting is
also not required for example for code $a = $b; developer writes the
comment like assigning value of $b to $a. Even layman programmer can
understand what is being done here. These kind of commenting is
useless. Instead programmers should write why this is done. We don't
need to teach programing language in our code instead we should document
how this program works
Not taking backup of your work
How
many times does it happen to you that you lost important and good piece
of work because you forgot to take backup or saved your programs and
your machine restarted or malfunctioned. There are ample tools
available in market now which gives you benefit like auto-saving,
versioning control system, etc. While working on the open source
projects I keep checking-in my code into SVN repository or Github which
are free to use softwares.
Not using debugging tools
Almost
every programming language comes with powerful debugging tool which
gives detail errors and help you identify the bugs in your code easily.
Some programming languages doesn't comes with inbuilt debugging tools
and in that case printing the statement on console or external debugging
tools are quite useful. For example, while doing the web programming, I
found developer tools like firebug extremely useful in not only finding
the code issues but also the performance issues also.
Start coding without understanding the programming language
Programming
languages are no different than our languages which we speak.
Programming languages have vocabulary, grammar and recommendations on
how to use it. Major mistake newbies usually do is start coding the
stuff without properly understanding the power of programming language
and end up writing lengthy codes which in fact can be done in couple of
lines and in no time.
Coding without concentrating on the design
Most
programmers are eager to start the coding for the new exciting project
at hand. In this hurry they forget to understand the design of the
program and end up creating something which is not customers wanted.
Customer is king for any market and even though you wrote fantastic
program which is not useful for customer then it would be of no use.
Most programmers doesn't understand the users perspective and only think
from the programmers perspective. Sometimes programmers codes features
which are not asked by the customer. This creates lots of problem. This
new feature is useful for the customer or not is another debate but if
customer has not asked for this feature then it might not be on his
priority list. Also, this features needs to be tested thoroughly so it
consumes more time whereas this time was scheduled for something else.
Also, most important because of free features given to customers,
companies might be loosing good revenue opportunity. So, moral of the
story is to stick to the design.
I hope you have enjoyed my list. Keep Coding and enjoy programming.
