My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more
The Six Common Mistakes Programmers do

The Six Common Mistakes Programmers do

Darlington Ehochi's photo
Darlington Ehochi
·May 27, 2020

First, can a programmer make a mistake in their code? before I start writing a computer program, the first thing I do is how can I figure out my mistake in my code. Programming is all about working smart and finding effective ways to build useful software. Whether you’re creating software programs, web apps, or mobile apps the principles of programming remain the same. When first learning to code it’s important to understand good habits and bad habits. Knowing mistakes coders make, and how to avoid them, can help you build a better foundation in your programming. These are some tips that tell the common mistakes programmers do.

1. 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. To make matters worse, severe security holes can arise when three or four seemingly benign holes are chained together. One programmer may let the client write a file assuming that the directory permissions will be sufficient to stop any wayward writing. Another may open up the permissions just to fix some random bugs. Alone there’s no trouble, but together, these coding decisions can hand over arbitrary access to the client.

2. Bad Variable Names: Variables are essential in programming no matter which language you’re working in. Because they are so widely used, it’s important to have good habits naming variables. Variables should be named accurately and neatly. Avoid using general terms that don’t mean anything. It’s quick and easy to throw something together, but when you need to come back to your code later it makes it much more difficult to figure out what is going on.

3. Not validating user input: A program must be very careful whenever it accepts external input. First, the program must make sure that user input doesn’t overflow some internal buffer. Second, if the program uses user input to build queries, it must make sure that said input doesn’t contain controls that can leak into the query. Failure to do these basic checks can make your program hackable and a danger to society. Beyond that risk, however, you need to make sure that what you’re reading is actually what you expect. This is normally done with markers.

4. Not Using Comments: Use comments! Comments are the documentation of your code. They’re the best way to describe what exactly is happening in your code as it grows. Sure, it seems a little bit more work to explain your code but you will be thanking yourself later. Write a brilliant function? Write a comment about what it does. Creating a new object template for Object-Oriented Programming? Break it down with a comment. Comments are used in every language, and they are there for a reason.

5. No Effective Planning: Writing effective software starts with good planning and design. If you wanted to build a house you would draw up a blueprint before building. Programming is no different. Before you even write one line of code, identify what you want to accomplish. Know what the problem is, how you want to solve it. If you try and figure problems out while you’re writing code, you may find yourself missing the right solutions. Separate the problem solving from the coding and life is good.

6. Not using a debugger: A debugger allows the programmer to step slowly through your code to better understand exactly what it’s doing. This step is critical for a program that’s not working but it’s just as important for a program that appears to be working fine. I don’t know the number of times that I’ve stepped through a function that is generating the proper results only to realize that the function is not working the way I want it to. Either it doesn’t handle all of the possible legal input values or more likely it doesn’t detect the possible invalid input values. The debugger gives you more information to work with when you need a more detailed understanding of what your program is doing.