4 Must-Do when coding
How to avoid mistakes and dignify your code
When it comes to working with new technologies, one of the biggest mistakes we do as programmers is to ignore the documentation. To find best practices, you should look at the code of other colleagues, not just your own. If you learn how to write code correctly, you can stand out from the competition and not use stereotypes.
- DOCUMENTATION
The documentation for a tool or library is created solely to facilitate the use of the tool in the work. If the user does not see the documentation, the development phase can take too long, and the library may not reach its full potential. To make life easier for you when using tools, you have never used before, read and understand this documentation.
When you talk about this topic, I must also stress the importance of writing a documentary. You may not be developing the latest code used by thousands of people, but simply writing what is in your code will be good enough. This is useful not only for the people who use the code, but also for your teammates who will build on it, and if you look at what you have written in a few years.
The documentation doesn’t have to look super professional, but a simple text document that describes what a piece of code does, what the input is and what the output is would be good enough.
2. COMMENT /**
Make sure you add one or two sentences at the beginning of each function you write, explaining what the function does and what your expected inputs and outputs are. If there is a complicated logic behind your function, write a few lines that do it for you.
You know what your inputs and outputs must be, and in everything you write there is an input and output. It’s not about the color or layout of your design, it’s about deciding what you enter in the code. There is a general course of the project that determines the design, and that is all you must do.
An example would be to download a CSV file from the Internet and send a request to the database, but in a targeted way. Take the time to develop your code and think about what you are going to do and try it out.
Know your big goals, be they short-term goals and try to achieve them at every stage of the project but know your bigger goals.
It is easy to lose track of time and even to lose sight of the concrete, tangible steps that you are trying to take. The Master Data Science method includes the planning of steps in the form of construction contracts. Before you start with the implementation, you need to answer some questions, and I like helpful coaching questions.
It is a bit abstract to say that you need to clean up your code, but I mean that you should not have anything that is not necessary for the code when you finish it.
Just decide what your style is, and if it’s not for you, tune it in exactly the way you would for any other project.
When naming variables, classes and functions, you need to choose your style and stick to it. This makes it easier to follow the code, but also has a positive impact on the quality of the data science code and overall performance.
One of the things to strictly observe is clear labels, so name your variables, functions, and classes as you name them. Data frames play a key role in your code, but they are not the only thing you need to think about.
Naming becomes easier as you gain experience. So, if you try to make it perfect, you should not get stressed, but keep it short and understandable for someone who would read your code. Programmers tend to download data, start a notebook, write code snippets, and leave the data on their desktop only when they really need it. This does not mean that you should call data packets where, where or at any time. Put them all in one folder and save them in the same folder as your other data frames.
3. DEBUG!
Debugging is the process of finding out what went wrong when something in your code breaks. This is one of the most common skills that new coders lack, even if they have a programming background. The problem is that, like everything else, it is a skill to learn, not an essential one.
Debugging is more than just staring at a screen and figuring out what is wrong. You need to know how to communicate with your code and understand what it is complaining about. This could include changing variable values, annotating lines, or printing the values of variables to see if everything works as expected.
This is a sort of scientific approach when you think about it, but that does not mean that the problem is over or should be addressed. If there is one thing, I can tell you about debugging, it is that only one thing changes when debugging takes place. So, if there is one thing you can tell me about debugging, it should probably be about it.
4. GITHUB
Maintaining your code on GitHub will help you make confident changes without being afraid to break anything. It helps you track what you’ve changed, and keeps you happy and cozy, and it doesn’t get deleted when someone leaves the store.
It gets trivial when new people come to your team to do the work, so everything stays nice and organized. You should also actively use it in your project: make it a habit to upload all the changes you are working on. Every time you leave a new part of the project, you make changes, but you should make them every time, not just once or twice.
First, if something breaks, it is trivial to use the latest working version, and if not, to use a different version of the code.
