6 Coding Mistakes that many developers make

6 Coding Mistakes that many developers make

If you’re able to avoid the common mistakes in this article, you will be able to write better and cleaner code.

If you’re able to avoid the common mistakes in this article, you will be able to write better and cleaner code.

This will not only be beneficial to you but also to the other developers that have to take a look at your code. So you’re not just doing this for yourself—you’re also doing your team a huge favor.

Here are some of those common mistakes that you should avoid.

1. Hard-Coding

Hard-coding is the software development practice of embedding data directly into the source code of a program or other executable objects, as opposed to obtaining the data from external sources or generating it at run-time.

Values that are hard-coded don’t allow for configuration; they are set in stone. Hard-coding is considered an anti-pattern or at least a very bad code smell.

Things that are being hard-coded the most, for whatever (sometimes maybe even valid) reason, are passwords and file locations.

A scenario where you see a lot of hard-coded passwords is for the authentication of an external service or API. Those credentials often get hard-coded, which isn’t considered best practice.

2. Non-Descriptive Naming of Variables

I can’t emphasize enough how important good variable names are. Most of the time, you are not the only developer working on a project. Other developers need to understand your code as well.

As I stated in that post, choosing good names takes time, but it saves more time than it takes.

3. Too Many Things Going On in One Function

According to the single responsibility pattern, a function should only be responsible for doing one thing. And one thing only. I’ve seen way too many functions that fetch, process, and present data all in one function. It’s considered better programming to split this up. One function that fetches the data, one that processes it, and another one that presents the data.

The reason it is important to keep a function focused on a single concern is that it makes it more robust. Let’s say that in the foregoing example the data got fetched from an API. If there is a change to the API—for example, there is a new version—there is a greater danger that the processing code will break if it is part of the same function. This will most likely cause the presentation of the data to break as well.

4. Commented-Out Code

We’ve all seen entire blocks of code containing multiple functions being commented out. No one knows why it’s still there. And no one knows if that block of commented-out code is still relevant. Yet, no one deletes that block of code, which is what you should really do with it. The reason no one deletes this block of code is that everyone assumes that someone else might need it.

Just delete that piece of commented-out code. Even though the code is not in the latest revision, if someone has plans with it the code is still available in version control. But that’s just my two cents.

5. Magic Numbers and String

Coming from non-descriptive naming of variables, we go to the next item on this list, which is about not assigning values to a variable. This is also known as magic numbers or strings.

A definition by Wikipedia:

Magic numbers are unique values with unexplained meaning or multiple occurrences that can and should be replaced with named constants.

Let’s take a look at the following code snippet:

for ($i = 1; $i <= 52; $i++) {
    ...
}

The number 52 in this example is a magic number. No one understands why that number 52 is there and what it represents. And why is it 52? Why can’t it be 64? Are those the number of weeks in a year?

What’s way more clarifying is:

$cardDeckSize = 52;

for ($i = 1; $i <= $cardDeckSize; $i++) {
    ...
}

Now everybody understands that we’re looping over all the cards in a deck. It gives context to other developers. On top of that, it’s much easier to change the value because it is not duplicated. It is stored in a variable only once.

Magic numbers are often used multiple times in different places within a program, which makes it error-prone.

The same can be said and done for strings:

if (userPasswordIsValid($user, "6yP4cZ".$password)) {
    ...
}

What is 6yP4cZ? It seems pretty random.

$salt = "6yP4cZ

if (userPasswordIsValid($user, $salt.$password)) {
    ...
}

Aha, now it makes sense!

6. Messy Formatting of Code

Messing up the formatting of code is something that is often done by people who don’t have a lot of programming experience. Most developers, with some years of experience, will probably nod their head if you ask them if they know a tester or data scientist who messed up the formatting of code. This comes from a lack of experience—unless they’re working with a programming language like Python, which saves you from a lot of this.

One of the most common ways to solve messy formatting is by using a linter. All modern IDEs also have the possibility to fix this for you. Sometimes you have to install a plugin, and sometimes it can be done out of the box.

Conclusion

If you find yourself hard-coding a lot of things, you should really take a critical look at your code, because most of the time it isn’t the best way to solve a problem.

Thank you for reading!

Functional Programming for JavaScript Developers

Functional Programming for JavaScript Developers

Functional Programming for JavaScript Developers. Learn Functional Programming and how it enables developers to move from imperative to declarative programming. Solidify your knowledge of functional JavaScript programming, including objects, arrays, and prototypes. Learn higher-order functions, closures, scope, master key functional methods like map, reduce and filter and promises and ES6+ asynchronous JavaScript. Learning how to build and manage asynchronous functional programs is perhaps the most important part of becoming an effective JavaScript programmer.

Functional Programming for JavaScript Developers

Learn functional programming and how it enables developers to move from imperative to declarative programming

Improve your code with functional patterns like pure functions, compose & map/reduce/filter...plus advanced concepts like fusion, transducing and monads!

Solidify your knowledge of functional JavaScript programming, including objects, arrays, and prototypes

Learn higher-order functions, closures, scope, master key functional methods like map, reduce and filter and promises and ES6+ asynchronous JavaScript. Go beyond the fundamentals of asynchronous JavaScript and use features and techniques that will help you reduce code and create smarter applications.

Learning how to build and manage asynchronous functional programs is perhaps the most important part of becoming an effective JavaScript programmer.

What you'll learn

  • On the surface, this course is designed for beginning and intermediate JS developers who want to learn the fundamentals in order to understand and use functional programming in both ES5 and ES6. However, this course is also perfect for people preparing to enter into competitive JavaScript bootcamps

Top 7 Programming Habits Make You a Better Programmer

Top 7 Programming Habits Make You a Better Programmer

In this post, we'll discuss Programming Habits You Should Adopt

Programming habits, we all have them. Both good and bad. But when you start adopting the right programming habits you can seriously boost your efficiency. Not only will these good habits impact you, but most likely they will also impact the people around you.

Like Denis Waitley said: “The truth is, you don’t break a bad habit; you replace it with a good one”. So that’s exactly why we’ll go over this list of seven programming habits that I think will make you a better programmer.

1. Small commits

Small commits make it possible for the developer to give a descriptive commit message. I’m sorry, but “fixed some issues” is not a descriptive commit message.

Your code gets easier to debug as well once you start making small commits. It’s easy to roll back to a previous commit to check whether a bug was introduced in that commit. Once you’ve found the commit where the bug was introduced there’s not a lot of code that could have caused this bug, since the commits are small.

Large commits can have a lot of bad consequences. Because so many things have changed in the commit, it is unclear what has actually changed.

And what about the person that has to do the code review? The reviewer will be afraid of merging the code because it’s just too many things to merge that can potentially break the code.

Code reviews get much easier with small commits. They make it possible to review one change at a time, giving the reviewer the opportunity to understand what is actually being changed.

2. Don’t repeat yourself

You’ve probably more than once reached the point where you look at a piece of code and think; well... this piece of code kind of looks the same as some code that I’ve written before.

This should ring a bell. Since it’s a situation that you want to avoid. Duplicate code makes your code smell really bad. Code gets harder to maintain since adjustments to this piece of code have to be made in multiple places. This makes it more likely that bugs sneak into the code.

It is considered good practice to follow the DRY (Don’t repeat yourself) principle. This means that once you start typing the same code you should probably refactor your code. Divide your code and logic into smaller reusable units and use that code by calling it where you want.

3. Once you think you’re done, refactor

Most programmers, especially those with not a lot of experience, think that their job is done once their code works as intended. But the word “done” includes more than just writing a piece of code for a fancy feature.

The code works, right? So what’s the point?

Yeah, you’re right. But before you hop on to the next task you should refactor your code. Refactoring your code will improve readability. Chances are that you didn’t produce the cleanest piece of code you’ve ever written. Some things may be clear to you, but how will other programmers feel about your code if they take a look at it? Be critical about this.

Refactoring can also help to reduce the complexity of the code, which will improve maintainability. In the long run, refactoring your code will pay for itself.

4. Focus on the business

Most programmers tend to be so focused on learning the tech stack that the business gets out of sight. On the journey to becoming a master of your tech stack, it’s important to keep the business in mind. Why are you building this?

Some developers are only interested in the technical aspects of their job. They don’t care about the business or the economic factors that justify their job’s existence.

Is what you’re working on creating value for the business or are you spending too much time on something that doesn’t really matter? It’s an important question to ask yourself.

5. Consistency is key

If you’ve decided to do camel casing for your variables, stick with it. Want to use spaces instead of tabs? Great! Whatever you’re doing in your code, at least do it consistently.

The problem with being inconsistent comes from the unavoidable fact that time destroys software. The longer a piece of software exists, and the more people that work on it, the more chaos comes in.

So what can you do to be more consistent?

One of the first things that you should do is pick a style guide. Once you have your style guide, stick to it. You could use a linter that checks your code for style issues.

The second thing is consistent naming. Variables, methods, and classes should be named in the same way. If you want to read more about creating good names in your code.

Just know that consistency has a high impact on the maintainability of your codebase!

6. Touch it once

I’ll fix it later. Yep, we’ve all heard that before. And we all know how often things got fixed “later”. You’re right. Never. Every time you see a TODO-comment you know someone failed to touch it once.

Work on a piece of code or user story from zero till it’s completely finished.

But what does completely finished mean?

It means that your code is refactored, for a start. Just like we discussed before. On top of that, your code needs to be tested. And testing is for most developers probably the least favorite part of their job. But there is more to testing than just clicking through the happy-path scenario. Make sure to test some other scenarios as well. And if you want to go the extra mile you could write some automated tests.

What’s left is the documentation. Is documentation required for this feature? Did you let the tester know how the feature can be tested? Are there any prerequisites that the tester needs to know about?

7. Never stop learning

New technologies emerge on a daily basis. And sometimes it might seem hard to catch up with all the latest trends. Though you should never stop learning. Because the day you stop learning is the day that you stop growing.

Learning new things is the only way to stay relevant in this ever-changing technology era that we’re living in.

Thank you for reading!