CODEX
6 things a beginner programmer should do to write cleaner code.
By Marquise Piton | A Student at the Awesome Inc. web development bootcamp.
Do you remember the first time you learned how to write code, or maybe you never wrote code in your life? You may have been confused about using the syntaxes, trying to understand the keyword “this,” or getting a jolt of satisfaction when figuring how to build a program on your own. That was me, but then I started to ask the question, “ How can I write cleaner code”?! I knew my functions were one unchecked if-condition from not working. I researched and read some books and came up with 6 things programmers should do to write better code.
Define the problem.
Before any code is typed, and I would even say before any pseudo code is written/drawn, make sure you know the main issue that needs to be solved. What does the client want? What do they want the application to do, or what is the main objective? These are the questions that need to be asked before any action. Ensure you are on the same page with the client and reiterate the problem to yourself, the team, or the client. Then write the problem out like a title on a movie poster so you can come back to it. Always stay in the lane to solving the problem.
Imagine and then draw.
I think drawing out the application of what it may look like is a good idea. This is my personal preference, and I find it helpful to think in an OBJECT-ORIENTED way and think about the different data structures or objects that I may want to use before writing my pseudocode. The client or designer may already give you a draft of what they want the app UI to look like. Perfect! Role-play a little. For example, think of yourself as the user and picture yourself clicking on a button. What do you or the client (if contracted) want that button to do for the user? What type of experience you want them to have? Once you have a mental image or drawing, you are ready to write some pseudocode!
Write pseudocode and then…. write some more.
If you decide to disregard the 2 paragraphs I wrote before, this one is the most IMPORTANT. Why?! Well, I found it challenging to write GOOD code, functions, classes, etc., without planning it out first. It’s definitely possible to write some witty code without planning out what needs to be done, but this behavior is not the best practice. Ngunyi Macharia has a great article, “How to write Pseudocode: A beginners’ guide,” on how to write pseudocode, and he goes into more detail. Write out what you want the app to do (define the problem), go through step by step of what you want the user to experience, write out the type of data structures and objects you might need to solve the problem, and write out the code in English.
Once you’re done “pseudo-ing.”, pseudo some more, go through the “what-if’s.” For example, if you’re following the MVC framework, do your functions and classes follow the standards. Don’t be afraid to spend time pseudo-ing for a while.
Think D.R.Y. and not W.E.T!
D.R.Y stands for “Don’t repeat yourself.” W.E.T stands for “We enjoy Typing.” D.R.Y is what you want to do, and W.E.T is what you DO NOT want to do. Check your code! Are you writing similar lines of code that could be iterated using a FOR loop, maybe? Are you writing unnecessary lines of code? What type of built-in functions can do the same output with one line of code instead of multiple lines. Go back to your pseudocode and rewrite. Always review your code and COMMENT your code. Here is an article that goes into more detail.
Let someone else read your code.
I always found someone else reading my code, like them opening up my diary/ journal to know what is going on in my head, which is mildly uncomfortable. It may take you a couple of hours or even days to get a function or just one line of code to work and then hear from your peers that you should reformat your code. Oof! It never sounds good to hear, but code review can lead to writing more efficient code. Don’t be scared to ask your peers to check out your code; you may have to do it anyway at your job if you are pair programming and make sure you leave descriptive COMMENTS for them to know what your programs or functions are doing.
Learn from examples
Browse around the internet. More than likely, the problem or application that you built, somebody else has already written. Compare your code to theirs and see the differences and similarities. Read books on good Design patterns or how to write clean code. Talk to senior devs and ask about the mistakes they made when they wrote code. I’m sure they will be happy to share their experiences.
Conclusion
These aren’t hard rules, but these 6 practices are what I found practical to write cleaner code. Some practices may take time to master, and personally, I’m learning every day how to be a better programmer. Take the time to think about some bad habits that you have when you are coding and then set a list of standards that could reinforce better habits. Happy coding!
Here are some must reads:
- Design Patterns: Element of Reusable Object-Oriented Software
- Pragmatic Programmer
- Algorithms
- Clean Code: A Handbook of Agile Software Craftsmanship
Looking for an Awesome bootcamp to help with your coding:
Social Media:
