Newbie Programming Mistakes We Can All Avoid
Tags: javascript, beginners, tutorial, webdev
Published: 2020-05-26 01:41:30

**Subscribe to my email list now at http://jauyeung.net/subscribe/**

**Follow me on Twitter at https://twitter.com/AuMayeung**

**Many more articles at https://medium.com/@hohanga**

**Even more articles at http://thewebdev.info/**

There’re some very common programming mistakes that we want to avoid.

In this article, we’ll look at how to avoid newbie programming mistakes that we may all make.

Not Breaking Down Code to Small Pieces
======================================

Modern languages all have many ways to break things down into small pieces. Therefore, we should use those features to break our code into small pieces.

They include features like modules, functions, and classes. We can put related code into modules so we only import the parts that we need.

If we have code that is run in multiple places, then we should put them into functions.

Classes are suitable if we make objects that have the same properties and methods in them.

Writing Code From Scratch to do Common Tasks
============================================

Most popular language’s standard libraries have lots of providing methods and objects to do things without writing all the code from scratch.

For instance, newbies in us may use loops to map values instead of using the array’s `map` method to map values from the original array to another for example.

If we don’t know about the standard library of the language that we’re using then we should learn those functions to clean up our code and save ourselves lots of time.

Looking for the Answer Before Trying to Solve the Problem
=========================================================

Solving problems will improve our thinking. It makes us wiser from exercising our brains.

Copying the answer from somewhere and use it as-is doesn’t take anything and so doesn’t stimulate our brain at all. Therefore, it’s just not good to lift the answer from somewhere and then use it directly before trying to solve our problem.

Too Much State and Side Effects
===============================

State and side effects are annoying since they’re hard to trace. Therefore, we should create pure functions as much as possible so that we don’t have to have store things in a centralized state unnecessarily.

Only things we really need to share should be put in their own state.

Side effects are actions that take place outside the function that it’s called from like modifying global state or saving files.

We should minimize those as much as possible since they’re also hard to trace and test.

Putting Everything as an Instance Method or Variable on a Class
===============================================================

Not everything needs to be a member of a class. If a class has things that are only in one object, then they don’t need to be in their own class.

For instance, we can just define an object literal that have their own properties. For languages that don’t have object literals, there’re always maps and dictionaries that can hold key-value pairs as object literals can.

Not Separating Concerns Cleanly
===============================

Separating concerns is important since we don’t want everything to be in one place. We want things that are related in one place.

For instance, we can make one module that does all the HTTP requests and another one that does price calculations for example.

Only if they logically make sense for them to be together then they should be put together.

Thinking That Typing Less Means Doing More
==========================================

Typing less is not doing more. For instance, a shorter variable name isn't better than a longer one that’s more descriptive.

For instance, `x` isn’t better than `numOranges` as a variable name. We should always use a more descriptive name like `numOranges` as a variable name.

Shorter code isn’t very readable in this case because no one knows what it means. The writer will probably once he or she left it for a few days.

However, syntactic sugar that is meaningful does make sense. Some good examples of syntactic sugar that make code shorter while keeping readability are things like the spread operator in JavaScript.

Overusing Frameworks
====================

Frameworks aren’t good for everything. We have to use the tool that makes sense for the job.

For instance, we don’t need a framework to make a simple web page for example.

For complex apps, frameworks make sense since it keeps our code organized and abstract out the hard parts that we don’t want to touch.

Conclusion
==========

Some newbie mistakes that people commit often are things like not cleaning up code and using shortcuts to make them look smart.

Those are things that some people commit, but once we all get more experience, we’ll be more mature and grow out of these mistakes quickly with some guidance.