Many enjoy programming and solving algorithmic mazes in their favorite language, but what nobody likes is diving into old code or even worse, code written by someone else.
\nI’ve had to do it several times, sometimes it was bad, other times worse, many times I end up rewriting part of the code that makes my eyes bleed, and that’s why I’ve learned some best practices when programming.<\/p>\n
Warning:<\/strong> This comes from a Data Scientist’s perspective, so these cases generally apply to ETL and Machine Learning models.<\/p>\n Many times I’ve seen that when people receive a task, they sit down and start pressing keys trying to accomplish what was requested, and that generally produces very bad code.<\/p>\n The lines of code written reflect the logic with which the developer solved the problem, so if they don’t have this logic clear, it will be a difficult thread to follow.<\/p>\n This will help you name variables, write comments and divide the code into parts.<\/p>\n With the appearance of interactive languages like Python, R and Julia among others, I’ve seen many times scripts that to be executed must be run in pieces, something like: run from line 10 to 35, then run lines 1 and 2, then take the result from that line and paste it into line 40.<\/p>\n That’s not programming, it’s spreadsheet-ing in R or Python.<\/p>\n Try to use predefined structures and when processing data, many of those processes will be ETL. If possible, follow these steps:<\/p>\n Try to have each script execute a particular task, saving the result in some storage for a next stage, which will only have in common that it reads the previously saved data.<\/p>\n It will help you return to the code in the future:<\/p>\n Don’t create variables with characters like You don’t want to lose all your work, or imagine that at some point you made a mistake and want to go back. Back up your work in something like GIT<\/strong>, there are very good online courses.<\/p>\n New tools for manipulating data are focused on doing so with data in tidy format or "long" tables.<\/p>\n \ud83d\udcd6 Tidy Data – Wikipedia<\/a><\/p>\n \u274c Bad – Wide format<\/p>\n \u2705 Good – Tidy\/Long format<\/p>\n It is recommended to use objects and\/or variables in their native format in the language and leave the formatting for the human eye until the end.<\/p>\n Same with dates:<\/p>\n With a Or in Python:<\/p>\n The code can have many parameters, but execution parameters, for example "execution date" or input file path, are better off being parametric.<\/p>\n It can’t be that to change an execution parameter it’s necessary to modify the code. These should be passed through the console or through some web interface:<\/p>\n In R:<\/p>\n In Python:<\/p>\n Even better, using What did you think? Can you think of any more? Cheers! \ud83d\ude80<\/p>\n","protected":false},"excerpt":{"rendered":"
\n\ud83d\udcad Think Before You Code<\/h2>\n
\n\u25b6\ufe0f Code Should Run Sequentially<\/h2>\n
\n\ud83d\udd04 If It’s an ETL, Give It an ETL Structure<\/h2>\n
\n
\n\u2702\ufe0f Divide the Code Into Parts<\/h2>\n
\n\ud83c\udff7\ufe0f Give Variables Good Names<\/h2>\n
\n
big_apple<\/code>. If you don’t like that standard, use another like bigApple<\/code>, but be consistent<\/strong><\/li>\n# \u274c Bad\ndef data(x):\n return x * 0.16\n\nt = data(100)\n\n# \u2705 Good\ndef calculate_tax(price):\n return price * 0.16\n\ntotal_tax = calculate_tax(100)<\/code><\/pre>\n
\n\ud83d\udd24 Don’t Use Non-ASCII Characters<\/h2>\n
\u00f1<\/code> or \u00e1\u00e9\u00ed\u00f3\u00fa<\/code> or even spaces. At some point it will be a problem.<\/p>\n# \u274c Bad\na\u00f1o_fiscal = 2024\npr\u00f3ximo_a\u00f1o = 2025\n\n# \u2705 Good\nfiscal_year = 2024\nnext_year = 2025<\/code><\/pre>\n
\n\ud83d\uddc2\ufe0f Use Version Control<\/h2>\n
# Basic commands\ngit init\ngit add .\ngit commit -m "Add tax calculation function"\ngit push origin main<\/code><\/pre>\n
\n\ud83d\udcca Work with Data in Tidy Format<\/h2>\n
\n\n
\n \nperson<\/th>\n weight_2020<\/th>\n weight_2021<\/th>\n<\/tr>\n<\/thead>\n \n Juan<\/td>\n 70<\/td>\n 72<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n\n
\n \nperson<\/th>\n year<\/th>\n weight<\/th>\n<\/tr>\n<\/thead>\n \n Juan<\/td>\n 2020<\/td>\n 70<\/td>\n<\/tr>\n \n Juan<\/td>\n 2021<\/td>\n 72<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \ud83c\udfa8 Data Formatting Goes at the End<\/h2>\n
# \u274c Bad - Formatting too early\ntax_rate = "16%"\nresult = float(tax_rate.replace("%","")) \/ 100 * price # unnecessary conversion\n\n# \u2705 Good - Work in native format\nTAX_RATE = 0.16\nresult = TAX_RATE * price\nprint(f"Tax: {result * 100:.1f}%") # format only at display time<\/code><\/pre>\nfrom datetime import date\n\n# \u2705 Work as Date object\ntransaction_date = date(2024, 1, 15)\n\n# Format only when displaying\nprint(transaction_date.strftime("%d-%m-%Y")) # 15-01-2024<\/code><\/pre>\n
\n\ud83d\udccb Generate an Execution Log<\/h2>\n
try<\/code> and catch<\/code> you can generate a log, for example in R:<\/p>\n#!\/bin\/Rscript\nsource("\/opt\/config\/init.R") # script containing log function and several other things\ntryCatch({\n # generally... process identified by destination table\n param = c(\n proc = 'process name'\n )\n\n ### do what's necessary here....\n\n write_log(param[['proc']], message = file)\n\n}, error = function(e) {\n write_log(param[['proc']], exit_code = -1, message = paste(e$message, collapse = " "))\n print(e$message)\n }\n)<\/code><\/pre>\nimport logging\n\nlogging.basicConfig(filename='execution.log', level=logging.INFO)\n\ntry:\n # main process\n logging.info("Process started successfully")\n\nexcept Exception as e:\n logging.error(f"Error in process: {str(e)}")\n raise<\/code><\/pre>\n
\n\u2699\ufe0f Parameters Don’t Belong in the Code<\/h2>\n
args = commandArgs(trailingOnly = TRUE)<\/code><\/pre>\nimport sys\nargs = sys.argv[1:]\nfile = args[0]<\/code><\/pre>\nargparse<\/code> in Python:<\/p>\nimport argparse\n\nparser = argparse.ArgumentParser()\nparser.add_argument('--date', default='2024-01-01', help='Execution date')\nparser.add_argument('--input', required=True, help='Input file path')\nargs = parser.parse_args()\n\nprint(f"Processing file: {args.input} for date: {args.date}")<\/code><\/pre>\n
\n\ud83e\udd14 Final Question \ud83d\ude0a<\/h2>\n
\nLeave it in the comments.<\/p>\n