5 Nooby Coding Mistakes You NEED To Avoid
The other common mistake is the mega function which attempts to do everything at a single location and the code writing is confusing and unmaintainable. By dividing such huge functions into manageable, but intellectually coherent units, you end up with cleaner code easier to comprehend and operate upon. This practice is not only a good practice of coding, but also has made your functions coding modular and self documenting thereby saving you the time when debugging or revising your software coding project.
The failure to consider edge cases is one of the everpresent traps during the coding process. A neophyte will think that successful execution of the program will always mean valid input, however, in the real world, when you do not anticipate other problems such as empty lists or wrong datatypes, your code can break. You can increase robustness of your checks, and error messages of the errors that people cannot see, and essentially program the code so that it is more robust and handle unexpected potential inputs gracefully without failing as a result of some kind of coding error that can be avoided.
davieasyo
Rated: 4 stars
5 Nooby Coding Mistakes You NEED To Avoid: https://www.youtube.com/watch?app=desktop&v=iwxPb0hOR4g&t=0s
Mistake 1: Nested If Statements (Staircase style)
The initial code snippet has several nested IF statements, which produces a diagonal "staircase" shape that is the result of too much indentation. It happens because the code is tested against a set of conditions (e.g. whether a number is not None, or more than zero and even and less than 100) before being added to a results list. Although this is suitable and applicable in simple cases, when there are more conditions to be applied, the structure will be too complex in a way that it cannot be read, understood, or changed. Deep nesting, which is commonly know as the staircase pattern, is the indication that the code should be simplified to enhance the understandability and maintainability of the code.
The better solution flattens the code as in decreasing indentation levels, instead of upside down logic of the conditions. Rather than making sure that every condition is false in order to add or have a number, the code will involve checks that will exclude a number (e.g. would exclude a number, so it has to be checked that it is not None, is within range of numbers and not an odd number). In case any of these conditions of being an "exclusion" condition, the code employs the continue statement, which will advance to the next loop increment, without having to go with the nested if blocks. This method can remove the staircase pattern and it leaves you with nearly flat code with little indentation, that is easier to read and maintains. Avoiding nested conditions: Deeply nested if statements make code hard to read and debug. We'll explore strategies for simplifying these structures. The perils of else if chains: Long chains of else if can become cumbersome and error-prone. We'll outline alternatives for cleaner conditional logic. Understanding Boolean expressions: Mistakes in writing Boolean expressions can lead to unexpected outcomes. This section clarifies common pitfalls and offers best practices for crafting reliable conditions.
The most important method of refactor code is the early continue statements which throws out invalid cases and then the rest valid numbers can be placed in the list with no checks at all. Conditions are grouped together ( e.g. testing whether a number is out of range or odd all in one if statement ) which prevents block nesting. This is common in loops and the leverages continue and break keywords allowing logic to be simplified, complicated details to be avoided, and to make multiple lines more readable. Although initially rendered counterintuitively, such a way of code simplification is prevalent and also productive to cut down nested excess.
Mistake 4: Mega Functions
Its original code is a mega function with many operations in a single one, like checking an order, managing prices, providing discounts, billing a customer and so on. This amounts to code that can hardly be interpreted within a shortest time; it takes much time and effort to deduce what the code is about. As an example, the functionality includes an input check to make sure that the input is a dictionary, the availability of items and customer information, calculations of total values, discounts, and payments within one block. This avoids a quick guess of what the particular function does and makes it prone to error when attempting to change certain aspects of the code (e.g. alter the logic behind a discount).
In the refactored solution, mega function is broken into smaller and narrower functions where each would do a specific job, validation of the order, calculating total price, discounts, making payments and sending confirmation messages. This is because, after calling the below sub-functions, this leaves behind a main process_order function being concise yet readable with only a handful number of lines. Reading the names of the functions alone, most people will know within seconds what the general purpose of the code is and where it is heading without having to wade through the implementationals. This is making the code self documenting, because the names of the functions make the intended use of the functionality clear and avoids the cognitive burden of parsing the program.
The gains of such a refactoring are important: the code can be maintained much more effortlessly, modified, and avoid errors. In case an update of a discount logic is necessary, the developers can approach the place of application directly to the referenced apply_discount without having to scroll through irrelevant code. Such modular structure increases the readability and scalability with the isolated functions being specific and dedicated to a single responsibility. Through lack of mega functions and dividing work into smaller, logical units, the code becomes more understandable, maintainable and cleaner, thus, the developer can understand and work with it in a short amount of time, even after a long duration.
Mistake 5: Forgetting to Check for Edge Cases
The original calculate_average function appears simple, summing a list of numbers and dividing by the list's length to compute the average. However, it fails to account for edge cases, such as an empty list, which causes a zero-division error when dividing by zero, or non-numeric inputs like strings, which trigger type errors (e.g., trying to add a string to an integer). These errors highlight a common mistake: assuming ideal input. In practice, especially when code is executed repeatedly with diverse inputs, unexpected values can break the function in unpredictable ways, making it essential to anticipate and handle such cases proactively.
The refactored solution makes the function robust by systematically checking for edge cases. It first verifies that the input numbers is a list, raising a TypeError with a clear message if it’s not, which helps users understand and fix their mistake. Next, it checks if the list is empty, returning 0 (or optionally raising a ValueError) to handle this case gracefully. The function then filters out invalid entries by ensuring each element is an integer or float, collecting only valid numbers. This approach ensures that even if some inputs are invalid (e.g., strings), the function can still compute the average of any valid numbers, avoiding errors and improving reliability.
This robust version of the function is "bulletproof" because it handles virtually any input scenario. If no valid numbers are provided, it returns 0 instead of crashing. By raising custom exceptions with descriptive messages for invalid inputs, it guides users toward correcting their errors. This practice of anticipating edge cases—such as empty lists, incorrect types, or mixed valid and invalid inputs—makes the code more reliable and maintainable. The key lesson is to avoid ambiguous return values (e.g., False) and instead use clear, custom exceptions and validation to ensure the function works predictably in all scenarios, enhancing both usability and debugging.
