Tips for Writing Readable Code

5 lessons I learned from reviewing code in 125+ interviews I've reviewed over 125 code snippets as an interviewer at Google and Amazon and trust me, clean code in an interview can be the difference between a "lean hire" and a "strong hire." Here are 5 tips to instantly improve your interview code: 1️⃣ Meaningful names: - Ditch x, y, and z. - Use names that describe the variable's purpose. - Example: item_count instead of x. - Makes your code so much easier to follow. - Imagine debugging code with variables like "value1" and "temp2" - a nightmare for both you and the interviewer! 2️⃣ Modular functions: - Break down large functions into smaller ones. - Each function should do one thing. - Instead of one giant calculate_discount() function. - Separate get_base_price(), add_coupon(), and calculate_final_price(). - This shows you can write organized and reusable code. 3️⃣ Pass by Reference: - When appropriate, pass variables by reference. - Avoids unnecessary copying. - Often makes your code faster. 4️⃣ Clean formatting: - Consistent indentation and spacing matter. - Make formatting while coding a habit. - Simple rule: Go to the next line after cleaning up the current one. - The interviewer would be more willing to help debug your code if they can see that it is length * (*width.begin()) and not length**width.begin(). 5️⃣ Readability is King: - Imagine the interviewer reading your code. - Is it easy to follow? - If not, refactor it. - Get rid of that nested ternary (?). - Instead use an if-else block for clarity. - I know being a one-line-coding-ninja feels great. - But it is wiser to not do that in our interviews. Start making these small changes. And trust me, you'll see a big difference - Your interviewers will love to help and work with your code more. 🌻 Let's make this post even more useful by sharing your top clean code tips! #cleancode #coding #interview #softwareengineering #tech #google #amazon

🧩 Why I stopped writing clever code. I started coding as a competitive programmer in high school. We were given five hours to solve five to ten hard algorithmic problems. Speed from thought to code matters. Code brevity matters. Even my typing speed matters. When I started working in a real company, I took a secret pride in writing short and clever codes, especially those magical one-liners. It made me feel quick and smart. I thought that it was a mark of expertise. But after the 17th "What does this line do?" DM, I felt that the problem was not my teammate's intelligence but rather my own code. If only me can understand and maintain the code, I haven't really built a system, I've made a puzzle 😂 🧑💻 I learned that readable code is about future-proofing my work: - The best code is written for humans first, computers second. - I'll thank myself 6 months later when I come back to fix a bug at 2am. - My new teammates will onboard faster. - Bugs are also caught earlier because the review is easier. ⁉️ How to make your code more readable? - Use clear, descriptive variable and function names. No more x, foo, or doStuff. - Write comments, but not essays. Explain the “why,” not the obvious “what.” - Break down complex logic into smaller, well-named functions. - Stick to consistent formatting and style. Clever one-liners may win you programming contests, but readable code wins you trust from your team 😉

You inherit someone else’s bioinformatics code. No comments. No structure. Variable names like x1, foo, temp2. And now it’s your problem. Let’s talk about that experience—and how to do better. 1/ Ever opened someone’s script and felt instant regret? No README No comments Hard-coded paths Copy-pasted blocks No functions You’re not alone. Code without structure is like a freezer full of unlabelled tubes. Sure, it runs. But good luck figuring out what anything does. 3/ Bad practices hurt you the most. Even if you wrote the code. You: “I’ll remember this later.” Also you (6 weeks later): “Who wrote this garbage?” Still you. 4/ On the flip side: Well-structured code feels like a gift. Functions are defined. Comments explain the logic. Each section is modular. You can re-use it. You can trust it. 5/ Here’s what I’ve learned from writing and inheriting messy code: Bad code punishes future you. Good code rewards collaborators. 6/ What are some good coding practices in bioinformatics? Use clear variable names Comment your logic, not just what each line does Break repetitive steps into functions Keep a README and usage example Use relative paths and config files 7/ Avoid this: x1 <- read.table("data.txt") temp2 <- x1[which(x1[,3] > 10), ] Prefer this: expression_data <- read.table("data.txt", header=TRUE) high_expr <- subset(expression_data, expression > 10) Make it obvious what’s happening. 8/ Turn repeated blocks into functions: filter_by_threshold <- function(data, column, threshold) { subset(data, data[[column]] > threshold) } Now your code is DRY (Don’t Repeat Yourself) and reusable. 9/ Keep outputs organized: mkdir -p results/qc mkdir -p results/plots If your outputs are sprinkled across your desktop, it’s time to rethink. 10/ Bonus: write a run_pipeline.sh that chains all your steps. Use snakemake or nextflow if it gets too big. Even a bash script with clear comments beats scattered commands. 11/ Want to learn how to write better code? Read other people’s good code. You’ll learn tricks no tutorial teaches. 12/ Good code is a form of respect. For yourself. For your collaborators. For the person who inherits your project next. Write like someone else has to read it. Because they will. 13/ Bioinformatics isn’t just about solving problems. It’s about communicating how you solved them. Your code is your paper in progress. Write it like you’re proud of it. I hope you've found this post helpful. Follow me for more. Subscribe to my FREE newsletter chatomics to learn bioinformatics https://lnkd.in/erw83Svn

In the last 11 years of my career, I’ve participated in code reviews almost daily. I’ve sat through 100s of review sessions with seniors and colleagues. Here’s how to make your code reviews smoother, faster and easier: 1. Start with Small, Clear Commits    - Break your changes into logical, manageable chunks. This makes it easier for reviewers to focus and catch errors quickly. 2. Write Detailed PR Descriptions    - Always explain the “why” behind the changes. This provides context and helps reviewers understand your thought process. 3. Self-Review Before Submitting    - Take the time to review your own code before submitting. You'll catch a lot of your own mistakes and improve your review quality. 4. Ask for Specific Feedback    - Don’t just ask for a “review”—be specific. Ask for feedback on logic, structure, or potential edge cases. 5. Don’t Take Feedback Personally    - Code reviews are about improving the code, not critiquing the coder. Be open to constructive criticism and use it to grow. 6. Prioritize Readability Over Cleverness    - Write code that’s easy to understand, even if it’s less “fancy.” Simple, clear code is easier to maintain and review. 7. Focus on the Big Picture    - While reviewing, look at how changes fit into the overall system, not just the lines of code. Think about long-term maintainability. 8. Encourage Dialogue    - Reviews shouldn’t be a one-way street. Engage in discussions and collaborate with reviewers to find the best solution. 9. Be Explicit About Non-Blocking Comments    - Mark minor suggestions as “nitpicks” to avoid confusion. This ensures critical issues get addressed first. 10. Balance Praise and Criticism    - Acknowledge well-written code while offering suggestions for improvement. Positive feedback encourages better work. 11. Always Follow Up    - If you request changes or leave feedback, follow up to make sure the feedback is understood and implemented properly. It shows you’re invested in the process. -- P.S: What would you add from your experience?

If you're a software engineer doing these three things, you may be making it harder for your teammates with dyslexia. Hey, I'm Bree, a software engineer and developer advocate, and I'm dyslexic. While I don't speak for everyone with dyslexia, here are three common habits that often make collaboration more difficult than it needs to be: 1️⃣ Skipping comments because “the code is self-explanatory.” It might be to you, but clear comments help me process and retain logic faster. When crafted correctly, they provide clarity and context. 2️⃣ Saying “Just read the code.” Reading code is a great way to learn and establish good programming habits, but this assumes that everyone processes when they're reading the same way. Reading ≠ comprehension. I might need to jump between files or revisit the same block several times before it clicks. 3️⃣ Using variable names that are too similar. Think: handleInput, handleInputs, inputHandler, handlerInput My brain blurs these together. Descriptive, distinct naming helps reduce cognitive load. At the end of the day, clean code is great. But inclusive code is better. Just because something is clear to you doesn’t mean it’s universally understandable. Thoughtful repetition, comments, and accessible naming conventions aren’t "extra." Write code as if someone different from you is going to maintain it.

I once looked at my early startup’s codebase and realised something uncomfortable… It wasn’t code. It was panic-driven typing disguised as progress. If you’ve ever hacked your way through a product deadline, you know this feeling. You move fast. You tape things together faster. And suddenly the whole system feels like a fragile Jenga tower held together by hope and coffee. The 6 rules I wish I had learned earlier, the ones that stop you from cleaning up your own chaos later. 1. Separation of Concerns When one function tries to do everything, it ends up doing nothing well. It’s like getting stock tips, relationship advice, and fitness routines from the same friend. Split responsibilities. Clean code starts with clean boundaries. 2. Document Your Code A comment today is a gift to your future self. Because your future self will have zero memory of the clever thing you wrote at 2am. Don’t make debugging a crime scene investigation. 3. Don’t Repeat Yourself (DRY) Copy-paste feels fast. It’s not. Every duplicate is a future bug waiting for its moment. Write once. Reuse everywhere. Let functions do the heavy lifting. 4. Keep It Simple Complex code looks impressive, until you’re the one maintaining it. The real flex is clarity. Readable > clever. Understandable > magical. 5. Test Driven Development (TDD) TDD is like writing the exam before studying. The test fails → you add logic → the test passes → you clean up. It forces discipline. It prevents surprises. It builds confidence you can’t get from vibes and manual testing alone. 6. YAGNI (You Ain’t Gonna Need It) Founders love planning for the future version of the product. Except most of those imagined features never ship. Focus on what users need now. Earn the right to build more later. So, treat your codebase like a campsite: Leave it cleaner than you found it. Your team and your roadmap will thank you. P.S. What’s the most chaotic codebase sin you’ve ever seen… that still haunts you to this day?

Boost your efficiency in your data role by writing clean, readable Python code! Here is how to make your code easier to read and maintain: 1. 𝗨𝘀𝗲 𝗠𝗲𝗮𝗻𝗶𝗻𝗴𝗳𝘂𝗹 𝗩𝗮𝗿𝗶𝗮𝗯𝗹𝗲 𝗡𝗮𝗺𝗲𝘀: • It should be clear what the variable contains and its data type    • 𝘌𝘹𝘢𝘮𝘱𝘭𝘦𝘴: order_dates_list, shop_adresses_df, distance_in_km, cost_in_dollar   2. 𝗞𝗲𝗲𝗽 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀 𝗙𝗼𝗰𝘂𝘀𝗲𝗱: • Aim at a single responsibility with each function do one thing and do it well.    • 𝘌𝘹𝘢𝘮𝘱𝘭𝘦: Split a 𝘤𝘭𝘦𝘢𝘯_𝘢𝘯𝘥_𝘱𝘳𝘰𝘤𝘦𝘴𝘴_𝘥𝘢𝘵𝘢(𝘥𝘢𝘵𝘢) function into a 𝘤𝘭𝘦𝘢𝘯_𝘥𝘢𝘵𝘢(𝘥𝘢𝘵𝘢) and a 𝘱𝘳𝘰𝘤𝘦𝘴𝘴_𝘥𝘢𝘵𝘢(𝘥𝘢𝘵𝘢) function.   3. 𝗨𝘀𝗲 𝗗𝗼𝗰𝘀𝘁𝗿𝗶𝗻𝗴𝘀 𝗮𝗻𝗱 𝗖𝗼𝗺𝗺𝗲𝗻𝘁𝘀: • Add a multiline string at the beginning of the function describing what it does and how to use it. • Descript the parameters and return values for the function.    • 𝘌𝘹𝘢𝘮𝘱𝘭𝘦: 𝘥𝘦𝘧 𝘤𝘭𝘦𝘢𝘯_𝘥𝘢𝘵𝘢(𝘪𝘯𝘱𝘶𝘵_𝘥𝘧):     """     Cleans the input dataset.     Parameters:     data (DataFrame): The raw input data.     Returns:     cleaned_df (DataFrame): The cleaned data.     """ 4. 𝗙𝗼𝗹𝗹𝗼𝘄 𝗣𝗘𝗣 𝟴 𝗚𝘂𝗶𝗱𝗲𝗹𝗶𝗻𝗲𝘀: • Stick to Python’s style guide for a uniform look and structure.    • 𝘌𝘹𝘢𝘮𝘱𝘭𝘦: using snack case for function and variable names, following the rules for line breaks and parenthesis.   5. 𝗟𝗲𝘃𝗲𝗿𝗮𝗴𝗲 𝗟𝗶𝘀𝘁 𝗖𝗼𝗺𝗽𝗿𝗲𝗵𝗲𝗻𝘀𝗶𝗼𝗻𝘀: • Use list comprehensions to create lists without the use of normal loops.    • 𝘌𝘹𝘢𝘮𝘱𝘭𝘦𝘴: squares = [num ** 2 for num in range(10)]   6. 𝗕𝗿𝗲𝗮𝗸 𝗗𝗼𝘄𝗻 𝗖𝗼𝗺𝗽𝗹𝗲𝘅 𝗘𝘅𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻𝘀: • Use intermediate variables for improved clarity.    • 𝘌𝘹𝘢𝘮𝘱𝘭𝘦𝘴:      𝘛𝘶𝘳𝘯      result = (a + b) * (c / d)      𝘪𝘯𝘵𝘰      sum_ab = a + b   division_cd = c / d   result = sum_ab * division_cd Readable code isn’t just for others, but also for future you. Make your Python code clear, maintainable, and professional to make everyone's live easier. What’s your top tip for writing readable Python code? ---------------- ♻️ Share if you find this post useful ➕ Follow for more daily insights on how to grow your career in the data field #dataanalytics #datascience #python #cleancode #careergrowth  

Best Practices for Writing Clean and Maintainable Code One of the worst headaches is trying to understand and work with poorly written code, especially when the logic isn’t clear. Writing clean, maintainable, and testable code—and adhering to design patterns and principles—is a must in today’s fast-paced development environment. Here are a few strategies to help you achieve this: 1. Choose Meaningful Names: Opt for descriptive names for your variables, functions, and classes to make your code more intuitive and accessible. 2. Maintain Consistent Naming Conventions: Stick to a uniform naming style (camelCase, snake_case, etc.) across your project for consistency and clarity. 3. Embrace Modularity: Break down complex tasks into smaller, reusable modules or functions. This makes both debugging and testing more manageable. 4. Comment and Document Wisely: Even if your code is clear, thoughtful comments and documentation can provide helpful context, especially for new team members. 5. Simplicity Over Complexity: Keep your code straightforward to enhance readability and reduce the likelihood of bugs. 6. Leverage Version Control: Utilize tools like Git to manage changes, collaborate seamlessly, and maintain a history of your code. 7. Refactor Regularly: Continuously review and refine your code to remove redundancies and improve structure without altering functionality. 8. Follow SOLID Principles & Design Patterns: Applying SOLID principles and well-established design patterns ensures your code is scalable, adaptable, and easy to extend over time. 9. Test Your Code: Write unit and integration tests to ensure reliability and make future maintenance easier. Incorporating these tips into your development routine will lead to code that’s easier to understand, collaborate on, and improve. #CleanCode #SoftwareEngineering #CodingBestPractices #CodeQuality #DevTips

𝐇𝐨𝐰 𝐓𝐨 𝐖𝐫𝐢𝐭𝐞 𝐁𝐞𝐭𝐭𝐞𝐫 𝐚𝐧𝐝 𝐂𝐥𝐞𝐚𝐧𝐞𝐫 𝐂𝐨𝐝𝐞 Explore these tips to write better code 👇 "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — Martin Fowler. I have seen a lot of experienced developers writing code that is hard to read and not enjoyable to work with. I am sure you have worked with such code. I am passionate about writing code that is easy to read and maintain. Today I want to share some actional tips that will make your code much better: 𝟏. 𝐍𝐚𝐦𝐢𝐧𝐠 When naming your variables, methods, and classes, ensure you give them clear and meaningful names. Good naming conventions enhance code readability. 𝟐. 𝐑𝐞𝐦𝐨𝐯𝐞 𝐑𝐞𝐝𝐮𝐧𝐝𝐚𝐧𝐭 𝐂𝐨𝐦𝐦𝐞𝐧𝐭𝐬 𝐢𝐧 𝐓𝐡𝐞 𝐂𝐨𝐝𝐞 Often poor naming leads to comments in the code explaining the intent. This is a bad practice. Such comments clutter your code, make it less readable and can become outdated. Your code is your source of truth. Comments should explain the WHY, not the WHAT. 𝟑. 𝐅𝐨𝐫𝐦𝐚𝐭 𝐂𝐨𝐝𝐞 𝐰𝐢𝐭𝐡 𝐈𝐧𝐝𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧𝐬 𝐚𝐧𝐝 𝐖𝐡𝐢𝐭𝐞𝐬𝐩𝐚𝐜𝐞𝐬 Proper code formatting enhances readability. Consistent indentation and spacing make it easier to follow the code's structure. 𝟒. 𝐑𝐞𝐝𝐮𝐜𝐞 𝐍𝐞𝐬𝐭𝐢𝐧𝐠 Deeply nested code is hard to read and maintain. The recommended practice is try to use not more than 2 levels of nesting. Reducing nesting improves code readability. 𝟓. 𝐑𝐞𝐭𝐮𝐫𝐧 𝐄𝐚𝐫𝐥𝐲 When conditions aren't met - return early from the method and prevent unnecessary code execution. Returning early from the method reduces nesting, and as a result, it improves code readability. 𝟔. 𝐆𝐞𝐭 𝐑𝐢𝐝 𝐨𝐟 𝐄𝐥𝐬𝐞 𝐊𝐞𝐲𝐰𝐨𝐫𝐝 Often when reading code in the else statement, you need to scroll up to see the corresponding if. After you add an early return, an else block becomes unnecessary 𝟕. 𝐀𝐯𝐨𝐢𝐝 𝐝𝐨𝐮𝐛𝐥𝐞 𝐧𝐞𝐠𝐚𝐭𝐢𝐯𝐞𝐬 𝟖. 𝐀𝐯𝐨𝐢𝐝 𝐌𝐚𝐠𝐢𝐜 𝐍𝐮𝐦𝐛𝐞𝐫𝐬 𝐚𝐧𝐝 𝐒𝐭𝐫𝐢𝐧𝐠𝐬 𝟗. 𝐂𝐨𝐧𝐭𝐫𝐨𝐥 𝐍𝐮𝐦𝐛𝐞𝐫 𝐨𝐟 𝐌𝐞𝐭𝐡𝐨𝐝 𝐏𝐚𝐫𝐚𝐦𝐞𝐭𝐞𝐫𝐬 𝟏𝟎. 𝐀𝐩𝐩𝐥𝐲𝐢𝐧𝐠 𝐭𝐡𝐞 𝐒𝐢𝐧𝐠𝐥𝐞 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐢𝐥𝐢𝐭𝐲 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝟏𝟏. 𝐂𝐨𝐫𝐫𝐞𝐜𝐭𝐥𝐲 𝐔𝐬𝐞 𝐁𝐫𝐚𝐜𝐞𝐬 { } 𝟏𝟐. 𝐃𝐨 𝐍𝐨𝐭 𝐑𝐞𝐭𝐮𝐫𝐧 𝐍𝐮𝐥𝐥 𝐟𝐨𝐫 𝐂𝐨𝐥𝐥𝐞𝐜𝐭𝐢𝐨𝐧𝐬 Want to become better at coding? --- ✅ If you like this post - 𝐫𝐞𝐩𝐨𝐬𝐭 to your network and 𝐟𝐨𝐥𝐥𝐨𝐰 me. ✅ Join 𝟑𝟓𝟎𝟎+ software engineers that are already 𝐫𝐞𝐚𝐝𝐢𝐧𝐠 my newsletter and are 𝐢𝐦𝐩𝐫𝐨𝐯𝐢𝐧𝐠 their .NET and architectural skills --- #csharp #dotnet #cleancode #refactoring #programming #softwareengineering #softwaredevelopment #bestpractices #softwaredesign

7 Simple Ways to Write Clean Code (Without Overengineering): 0. Meaningful names: 🔴 data, obj, temp, x give zero context. ✅ Use names with intention, like userList, shoppingCart, or isBuyValid. 1. Small functions, single purpose: 🔴 A 200-line function that does everything from validation to sending emails. ✅ Write functions that do one thing. If you can name it with "and," it's doing too much. 2. Consistent style and linting: 🔴 Inconsistent formatting makes code hard to read and review. ✅ Use a linter (ESLint, Prettier) to automate consistency and catch subtle bugs. 3. Don't repeat yourself (DRY): 🔴 The same validation logic is copied in 12 different places. ✅ Abstract repeated code into a single function, module, or class. 4. Comment the why, not the what: 🔴 Comments like i++ // increment i are just noise. ✅ Use comments to explain confusing business logic or the reason behind a complex decision. 5. Avoid deep nesting: 🔴 "Callback hell" or 10 levels of if statements are impossible to follow. ✅ Return early, use promises/async-await, and flatten your code structure. 6. Write tests: 🔴 You're afraid to change code because you don't know what will break. ✅ Unit tests act as a safety net and documentation for how your code is supposed to work. What did I miss?