Sam Burns’ Post

What is good code? It’s the code you never have to write. By that, I mean code that handles various scenarios simply by adjusting a configuration file instead of adding endless if-else conditions. If you are doing this, you’re already ahead of 95% of developers. Good code minimizes complexity and lets you focus on solving problems rather than rewriting logic.

When you are given an incomplete code of someone else's work to complete. Do you refactor the codes based on your understanding of how the developer could have done it easily, Or you flow with the code and provide a solution to each obstacle you could have avoided with your refactor. Let me know your answer in the comments section.

Here's an explanation of coupling. Given a specific change you need to operate on a codebase, two types or functions are coupled if and only if when one changes the other one must also change accordingly. There are many reasons why coupling could exist e.g. the same hardcoded value in multiple places under the expectations that all places use the same value at runtime. Coupling is not something you can zero, as your system is the product of the interactions of its types and functions. Reasoning about coupling is only useful within the context of a specific type of change. Good chances are there are always changes that require any 2 types or functions to change together. Moving the project into another folder is a trivial example. So what's the problem with coupling? The issue is that whenever some types or functions are coupled for a specific change type, you must change them in lock step, or things will stop working. This has 2 implications: 1. You might forget or do this incorrectly. This happens the furthest away the types and functions are, both organizationally and logically. This is why keeping modules cohesive and organised around purpose is important. 2. It increases the effort needed to go from a working state to the next working state, when performing the change. If I need to change some things across 4 types, my code won't work until I change all 4. This last point is a much bigger deal than it sounds. And that's because coupling tends to ripple through a codebase. You change B because you changed A in a way, but this change in B now requires C to change, then D, and so on. Sounds familiar? This is how small changes end up becoming large and risky endeavours. Large, because changes to types pull changes to other types. And risky, because you cannot checkpoint after taking a safe small step, since things won't work until all the changes in the coupled types will be done, recursively. There you are, I hope that I clarified what coupling is, when it becomes problematic, and why conscious and ongoing decoupling efforts are key to keeping the cost of changing a codebase manageable. Let me know what you think, especially if you disagree! PS: it'd be impossible not to mention the excellent work Kent Beck has done explaining coupling and other concepts in his book Tidy First, which I highly recommend.

Functions are reusable blocks of code that perform specific tasks. They enhance code organization and efficiency. Declaration: Create a function using the function keyword, followed by a name, parameters (optional), and code within curly braces. Parameters: Placeholder values passed to a function when called. Arguments: Actual values passed to a function when it's invoked. Return: Functions can optionally return a value using the return keyword. Types: Function declarations, expressions, and arrow functions. Scope: Functions have their own scope for variables, preventing conflicts. By breaking down code into functions, you improve code readability, maintainability, and reusability.

Every developer should write as little code as possible. Here's why: More code means more potential bugs. More code means more code to maintain. More code means more effort to rewrite later. Strive for less, more readable code.

𝗖𝗹𝗲𝗮𝗻 𝗰𝗼𝗱𝗲 𝘁𝗶𝗽: 𝗨𝘀𝗲 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝗹𝗲𝘃𝗲𝗹 𝗼𝗳 𝗶𝗻𝗱𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗲𝗿 𝗺𝗲𝘁𝗵𝗼𝗱 This 𝗲𝗻𝗵𝗮𝗻𝗰𝗲𝘀 𝗿𝗲𝗮𝗱𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗮𝗻𝗱 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗮𝗯𝗶𝗹𝗶𝘁𝘆 by ensuring 𝗺𝗲𝘁𝗵𝗼𝗱𝘀 𝗮𝗿𝗲 concise and 𝗳𝗼𝗰𝘂𝘀𝗲𝗱 𝗼𝗻 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝘁𝗮𝘀𝗸 — kind of like reading a document with clear and distinct paragraphs. Each method (representing a paragraph) maintains a specific level of abstraction, guiding the reader through the code's logic without overwhelming them with details. Adopting this approach not only improves code cohesiveness and reusability, but I also found it 𝘀𝗶𝗺𝗽𝗹𝗶𝗳𝗶𝗲𝘀 𝘀𝘁𝗮𝗰𝗸 𝘁𝗿𝗮𝗰𝗶𝗻𝗴 and eases understanding by keeping unnecessary details out of a method's concern. You might say that this strategy makes is harder to read the whole context of the class, because you have to hop in and out of methods to understand the context. I disagree with this idea, as you are normally 𝗿𝗲𝗮𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗰𝗼𝗱𝗲 𝗮𝘀 𝘁𝗵𝗼𝘂𝗴𝗵 𝗶𝘁 𝘄𝗲𝗿𝗲 𝗮 𝘀𝗲𝘁 𝗼𝗳 𝗧𝗢 𝗽𝗮𝗿𝗮𝗴𝗿𝗮𝗽𝗵𝘀, each of which is describing the current level of abstraction and referencing subsequent TO paragraphs at the next level down. Sticking by this rule actually facilitates a smoother navigation through code by adhering to a single level of abstraction. This is just one tip though. 𝗜'𝘃𝗲 𝘄𝗿𝗶𝘁𝘁𝗲𝗻 𝗮 𝗱𝗲𝘁𝗮𝗶𝗹𝗲𝗱 𝗮𝗿𝘁𝗶𝗰𝗹𝗲 𝘄𝗵𝗶𝗰𝗵 𝗶𝗻𝗰𝗹𝘂𝗱𝗲𝘀 𝟵 𝗺𝗼𝗿𝗲 𝘁𝗼 𝗵𝗲𝗹𝗽 𝘆𝗼𝘂 𝘄𝗿𝗶𝘁𝗲 𝗰𝗹𝗲𝗮𝗻 𝗰𝗼𝗱𝗲: https://lnkd.in/djm2qTVp

Increase Code Efficiency by using 𝗗𝗶𝗰𝘁𝗶𝗼𝗻𝗮𝗿𝘆 𝗖𝗼𝗺𝗽𝗿𝗲𝗵𝗲𝗻𝘀𝗶𝗼𝗻𝘀! For loops build dictionaries but can be verbose and inefficient. They require multiple lines for iteration and conditionals, cluttering the code. 𝗗𝗶𝗰𝘁𝗶𝗼𝗻𝗮𝗿𝘆 𝗰𝗼𝗺𝗽𝗿𝗲𝗵𝗲𝗻𝘀𝗶𝗼𝗻𝘀 allow dictionary creation in a single line. They enhance readability and efficiency, clarifying intent and reducing errors. However, avoid them when logic is complex or involves multiple steps.

If you've divided your application into parts then it's essential to consider reusable code and maintain it at a global level. In the screenshot below, each file duplicates the same functionality four times over. Now, either I refactor it or make a change in all 4 files consistantly.

Of late, I have seen code reviews go a bit sideways especially with people taking questions as a critique on themselves. While it is universally accepted that a critic on a change request is not a critic on us but should be seen as a genuine attempt by the reviewer to improve the quality of the codebase we are all contributing to and thereby, maintaining together, there are moments where we miss this. We are all human after all. Another thing I have observed of late is where individuals point to a snapshot of a decision as an answer to a question raised and expect that to suffice. Ideally that should suffice if the note/description is clear enough but if a follow-up happens, it is always a good practice to take it into your stride. In this regard, I would like to refer to The Standard of Code Review guidelines I have kind of fallen back to in times of such dilemma.

Don't hide the code! `Code Navigation` is hell important for readability and maintainability! If I find a code path that I have to go through 100 different places just to see and track logic, it just leaves me in a maze! Yes, it's all abstraction and some clean code tips that a method should be less than 20-50 lines, if you're going to split a method to 100 nested methods for the sake of reducing complexity, I bet will be more complex than before! It becomes worse if you put those methods into different interfaces! Don't hide the code!