Silly mistakes junior python programmers do, that make them look like interns

Any experienced person will be annoyed , if you do stupid things, and damage your image in worst case. python is easy, but its also easy to make mistakes provided dozens of entry level tutorials available online which most of the times skip industry best practices.

the good side is you will find it easy, the bad side is it not the best method to do things, and your technical debt will increase if you blindly follow.

in this article we will cover some aspects where beginners can do better. and following it will definitely help their code to look more presentable infront of other developers.

from module_name import *

Importing everything from a module might look easy for small projects, but imagine when you are building some software for a robot, and you import "walk" from os library which is used to scan files , and you also have a "walk" function which actually makes the robot walk by interfacing with hardware. now you run into problem! the one which is defined later overrides the previous function.

import os
os.walk("some_folder") #returns list of openable paths/files

def walk(destination):
    motor1.rotate()
	return "success"

something of this sort , ie explicitly calling os.walk always removes confusion.

using naming from other languages

lets say you want to name a variable which stores output of sum of given numbers in an array, in java/JS or Cpp you could do something like this sumOfNumbers, but in python naming standard, its a good practice to name it this way sum_of_numbers. but you can go one level further and be more elegant, just keep the variable names simple and concise , and simply put summation or sum that is perfectly fine if there is no other conflicting name i the file.

beware of using capitalized variable declaration from C, and dont use stuff like define SUMOFNUMBERS, its wrong in many ways, as capitalized naming must only be used when you know it is a very important variable, or you know flow of the program affects heavily using this variable. in case of SUMOFNUMBERS , its an arbitrary result and valid only until sum is calculated, and can be discarded.

expanding more upon capitalized variables, you can use them for meta variables like Thread count THREADS = 5, as multi threading heavily affects program behaviour.

make a huge file code.py which has all functionality.

as a rule of thumb, once you exceed 100 lines, its almost always a good idea to split your code. this will save your time! time to switch between files is negligible, but compared to scanning 100s of lines in the huge code.py file to make a small change, is not worth.

on the other hand you have inbuilt debugging tools for python which will definitely help you trace where exactly the error is coming and from which file.

another hidden advantage is that , this strategy follows divide and conquer strategy, so you wont feel lost, staring at screen with ocean of code, when something goes wrong, you will know exactly to which file to look for, and you will have much smaller code to deal with.

less is more

when i was a junior python developer, i thought more lines of code === more work done. no, never. its all about getting the task done in shortest possible time (time is money), and maintaining good code quality.

by good code quality i mean ,when you look back at your own code after few weeks, it should not feel like an alien technology! plus your team mates should understand, " what this guy was trying to do"

in other words, make your code as few lines as possible, use inline commenting

userdata = DB.find(uid) # comment in this way for easier readability

# not like  this : multiline
#this variable will lorem ipsum
#dolor si amet etc etc
userdata = DB.find(uid) 

not writing tests

this is perhaps single most deciding factor for any code project for any language. a great philosopher once said

you cant improve what you cant measure

by writing proper , meaningful tests, one can debug and fix the code faster. and ensure adding new features does not break old ones. infact one must follow test driven development. which means , write the tests first, and then do the development. its a very good practice, and saves you hours of manual labour and confusion if some feature is not working properly.

you might be wondering what test driven development is

To provide a definition, TDD is a technique in which you first write a test case, then develop the smallest portion of code needed to pass that test. This is contrary to typical development models in which feature development precedes test case creation. One notable feature of TDD is that it builds testing directly and prominently into the software development process, ensuring that the smallest portions of code within a piece of software work as expected.

small recipe for doing TDD in your project, start right away!

1. A developer writes a test for a new feature based on specifications.
2. The developer runs all existing tests. The newly created test should fail because the code for its feature hasn’t been written yet. This validates that the test was needed.
3. The developer writes the simplest code needed to get the test to pass.
4. The developer refactors the new code to improve the code’s readability and maintainability.
5. The developer repeats the process, eventually collecting new tests for every intended feature of the code.