Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

Addressing The Underworld of Software Engineering: Fixing Those Nasty Code Gremlins and Whimsical Architectures

Posted on Sep 26 Well, well, well. If it isn't another beautiful day in the software engineering paradise—a world where every line of Code is a hymn, and architectures are as harmonious as a Mozart symphony! Or, maybe not. Let's face it, as much as we'd like to pretend we are the Michelangelos of coding, even the Sistine Chapel had its initial sketches (and possibly some eraser marks). But fear not, brave coder! Today, we delve into the grimy underworld of coding mistakes and architectural anomalies that make our software "special," and of course, how to exterminate these gremlins with the poise of a professional.Ah, the joy of following a codebase that resembles a Jackson Pollock painting. Lines of code are splattered across the canvas with reckless abandon. How poetic!Both examples above show how not to structure code. Nesting multiple conditions or loops makes the code unreadable and unmaintainable.Global variables are like the village gossips. They know everything about everyone and are never shy to spill the tea. However, using too many global variables can lead to unpredictable behavior.These examples indicate that the variable global_var or globalVar can be modified anywhere in the code, making debugging a nightmare.When we say "this software is flexible," we usually don't mean that it's hardcoded to within an inch of its life.While this query looks innocent, hardcoding the status 'active' makes it rigid and difficult to change later without editing the code itself.One object to rule them all, one object to find them, one object to bring them all, and in the darkness bind them. The God Object is the Napoleon of the codebase.This class tries to do too much. It's an anti-pattern because it violates the Single Responsibility Principle (SRP).Your entire application is built upon a framework that no one understands, a.k.a, the Big Ball of Mud.Including everything in one file, or a small number of files, makes the architecture difficult to comprehend, maintain, or scale.Whether it's an old home or a chaotic codebase, the allure of a fixer-upper is undeniable. In this riveting chapter, we will unveil the mystical arts of code transformation. We'll not just annihilate the gremlins in your code but also understand why they appeared in the first place so that we're not setting the table for a second feast.Are you drowning in a plate of spaghetti code? There's no need to be a hero and tackle it all in one go. The first order of business is to declutter. Take that gigantic, abominable doEverything() function and break it down into smaller, digestible pieces.What we're doing here is simple but impactful. By carving out calculate_tax and apply_discount from the monolithic function, we're making the code more readable, maintainable, and reusable. Each function can now be individually improved, tested, or even rewritten without sending shockwaves through your entire codebase.You remember the gossipy global variables, don't you? Well, it's time to introduce some etiquette into their lives. The best practice here is to encapsulate these variables within the scope of functions or objects, making them mind their own business.Look at that! The variable total is confined to the calculateTotal function, making sure it doesn't roam around causing chaos. By keeping variables in local scopes, you avoid a host of unforeseen bugs and substantially reduce your future debugging time.Who likes to be put into a box? Not you, not me, and certainly not your code. Hardcoding is a no-no if you want your application to adapt to different scenarios. Replace those hardcoded values with dynamic configurations or, even better, environment variables.This little trick adds a layer of flexibility you wouldn't believe. The USER_STATUS can now be changed without even touching the source code, making your application not just adaptable but also easier to manage and more secure.Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Darpan Vithani - Sep 15 Adam Nathaniel Davis - Sep 13 Cruip - Sep 5 joan? - Aug 27 Once suspended, lordneic will not be able to comment or publish posts until their suspension is removed. Once unsuspended, lordneic will be able to comment and publish posts again. Once unpublished, all posts by lordneic will become hidden and only accessible to themselves. If lordneic is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Lord Neic. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag lordneic: lordneic consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging lordneic will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.



This post first appeared on VedVyas Articles, please read the originial post: here

Share the post

Addressing The Underworld of Software Engineering: Fixing Those Nasty Code Gremlins and Whimsical Architectures

×

Subscribe to Vedvyas Articles

Get updates delivered right to your inbox!

Thank you for your subscription

×