{"id":7550,"date":"2025-03-13T09:24:25","date_gmt":"2025-03-13T08:24:25","guid":{"rendered":"https:\/\/blog.bart.sk\/en\/?p=7550"},"modified":"2025-08-06T09:18:12","modified_gmt":"2025-08-06T07:18:12","slug":"coding-without-chaos-9-best-practices-for-sustainable-code","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/coding-without-chaos-9-best-practices-for-sustainable-code\/","title":{"rendered":"Coding Without Chaos: 9 Best Practices for Sustainable Code"},"content":{"rendered":"\n

Imagine revisiting your old project after months or even years. You open the code, feeling a wave of nostalgia, but then\u2026 what on earth does this variable x1y2z<\/code> mean? Who wrote this 300-line function? And why are there no comments anywhere?! Then it hits you\u2014it was you.<\/p>\n\n\n\n

Why Write Clean Code?<\/strong><\/h3>\n\n\n\n

Because developers spend 90% of their time reading<\/strong> code, not writing it. Clean code isn\u2019t just about aesthetics\u2014it\u2019s an investment in your future and your team\u2019s sanity. If you want your project to survive beyond a sprint demo and not be cursed by every developer who touches it after you, keep reading. <\/p>\n\n\n\n

1. Use Meaningful Names<\/strong><\/h2>\n\n\n\n

Which version makes more sense to you?<\/p>\n\n\n\n

\u274c Not Recommended:<\/strong><\/p>\n\n\n\n

function cx(d) { \n   return d[0]; \n}<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function getFirstElement(data) { \n   return data[0]; \n}<\/code><\/pre>\n\n\n\n
Saving a few keystrokes today could cost you (and everyone else) countless hours deciphering cryptic names later. Plus, in JavaScript, the minifier already optimizes names for you\u2014so there\u2019s no need to shorten them manually.<\/p>\n\n\n\n
2. Write Functions That Do One Thing Well<\/strong><\/h2>\n\n\n\n
If your function has more responsibilities than the average full-stack developer, something\u2019s off.<\/p>\n\n\n\n
\u274c Not Recommended:<\/strong><\/p>\n\n\n\n
function processUserData(user) { \n   validateUser(user); \n   cleanUserData(user); \n   saveUserToDb(user); \n   sendWelcomeEmail(user); \n}<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function validateUser(user) { \/* ... *\/ } \nfunction cleanUserData(user) { \/* ... *\/ } \nfunction saveUserToDb(user) { \/* ... *\/ } \nfunction sendWelcomeEmail(user) { \/* ... *\/ }<\/code><\/pre>\n\n\n\n
Smaller, single-responsibility functions make your code more flexible, reusable, and easier to test.<\/p>\n\n\n\n
3. DRY \u2013 Avoid Repeating Yourself<\/strong><\/p>\n\n\n\n
Copy-pasting the same code across multiple places is a recipe for maintenance nightmares. Stick to the DRY (Don’t Repeat Yourself)<\/strong> principle.<\/p>\n\n\n\n
\u274c Not Recommended:<\/strong><\/p>\n\n\n\n
function getAdminEmail(admin) { \n   return admin.email; \n} \nfunction getUserEmail(user) { \n   return user.email; \n}<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function getEmail(entity) { \n   return entity.email; \n}<\/code><\/pre>\n\n\n\n
One update, and it works everywhere. Smart and efficient!<\/p>\n\n\n\n
4. Comment Only When Necessary<\/strong><\/h2>\n\n\n\n
The best comment is the one you don\u2019t need to write because your code is self-explanatory.<\/p>\n\n\n\n
\u274c Not Recommended:<\/strong><\/p>\n\n\n\n
\/\/ This variable counts loop iterations \nlet i = 0;<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
\/\/ Tracks connection attempts to prevent infinite loop \n\/\/ in case of repeated failures. \nlet iterationCount = 0;<\/code><\/pre>\n\n\n\n
When commenting, explain the why<\/strong>, not the what<\/strong>.<\/p>\n\n\n\n
5. Proper Formatting Boosts Readability<\/strong><\/h2>\n\n\n\n
Well-formatted code is easier to read and work with.<\/p>\n\n\n\n
\u274c Not Recommended:<\/strong><\/p>\n\n\n\n
function foo ( x,y ) { \n   return x+y; \n}<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function foo(x, y) { \n   return x + y; \n}<\/code><\/pre>\n\n\n\n
Use linting<\/strong> and auto-formatting<\/strong>. A five-minute setup saves you hours of frustration.<\/p>\n\n\n\n
6. Handle Errors Gracefully<\/strong><\/h2>\n\n\n\n
Never assume everything will work flawlessly. That\u2019s why we have try-catch<\/code>\u2014to prevent your application from crashing at the worst possible moment.<\/p>\n\n\n\n
\u274c Not Recommended:<\/strong><\/p>\n\n\n\n
function readFile(filePath) { \n   let file = open(filePath, 'r'); \n   let content = file.read(); \n   file.close(); \n   return content; \n}<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function readFile(filePath) { \n   try { \n      return fs.readFileSync(filePath, 'utf-8'); \n} catch (error) { \n   console.error('Error reading file:', error); \n   return null; \n   } \n}<\/code><\/pre>\n\n\n\n
You don\u2019t want your entire application to break just because someone accidentally deleted a file, do you?<\/p>\n\n\n\n
7. Tests Save You from Disaster<\/strong><\/h2>\n\n\n\n
Without tests, your code is like a parachute you forgot to check before jumping.<\/p>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function add(a, b) { \n   return a + b; \n} \nunction testAdd() { \n   console.assert(add(2, 3) === 5, 'Test failed'); \n   console.assert(add(-1, 1) === 0, 'Test failed'); \n} \ntestAdd();<\/code><\/pre>\n\n\n\n
If something goes wrong, you want to catch it before your boss or customer does.<\/p>\n\n\n\n
8. Fewer Dependencies = Fewer Problems<\/strong><\/h2>\n\n\n\n
Over-relying on external libraries can backfire. A perfect example is the infamous left-pad npm<\/strong> incident. In 2016, a developer removed the small left-pad<\/strong> package from npm<\/strong>, causing thousands of projects across the internet to break instantly. This event highlighted the risks of depending on external libraries for simple operations. You can read more about it here<\/a>.<\/p>\n\n\n\n
\u274c Not Recommended:<\/strong><\/p>\n\n\n\n
import _ from 'lodash'; \nfunction calculateSum(data) { \n   return _.sum(data); \n}<\/code><\/pre>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
function calculateSum(data) { \n   return data.reduce((acc, num) => acc + num, 0); \n}<\/code><\/pre>\n\n\n\n
Use third-party libraries wisely\u2014only when they are truly necessary.<\/p>\n\n\n\n
9. Refactoring Is Essential<\/strong><\/h2>\n\n\n\n
Refactor continuously\u2014otherwise, your old code will soon feel like a tangled mess.<\/p>\n\n\n\n
\u2714 Recommended:<\/strong><\/p>\n\n\n\n
\/\/ Original Code \nfunction calculateDiscount(price, discount) { \n   let discountedPrice = price - (price * discount \/ 100); \n   return discountedPrice; \n} \n\n\/\/ Refactored Code \nfunction calculateDiscount(price, discount) { \n   return price * (1 - discount \/ 100); \n}<\/code><\/pre>\n\n\n\n
Simpler, cleaner, better.<\/p>\n\n\n\n
Final Thoughts: Clean Code, Easier Life<\/strong><\/h2>\n\n\n\n
Clean code isn\u2019t just about looking neat\u2014it\u2019s about being understandable, maintainable, and efficient<\/strong>. At Bart, we know that well-written code saves time, reduces frustration, and cuts costs. And if you love writing clean, structured code as much as we do, you might just feel right at home with us. \ud83d\ude09<\/p>\n\n\n\n
Clean Code \u2013 Frequently Asked Questions<\/h2>\n\n
\n  Should I refactor old code that already works?<\/summary>\n  
If you\u2019re never going to touch it again \u2013 maybe not. But if someone (even you) will need to maintain it later, refactoring is worth it. The later you do it, the harder it gets.<\/p>\n<\/details>\n\n\n
\n  When are comments actually useful?<\/summary>\n  
When they explain why<\/strong> something is being done, not just what<\/strong>. A good comment gives context or warns about something non-obvious. A bad comment just restates what\u2019s already clear in the code.<\/p>\n<\/details>\n\n
\n  How do I start writing cleaner code?<\/summary>\n  
Start with the basics: use clear names, split big functions, avoid repeated code, use a linter, and write tests. You don\u2019t have to refactor everything at once \u2013 small improvements make a big difference over time.<\/p>\n<\/details>\n\n\n
\n  Should I refactor old code that already works?<\/summary>\n  
If you\u2019re never going to touch it again \u2013 maybe not. But if someone (even you) will need to maintain it later, refactoring is worth it. The later you do it, the harder it gets.<\/p>\n<\/details>\n\n\n
\n  When are comments actually useful?<\/summary>\n  
When they explain why<\/strong> something is being done, not just what<\/strong>. A good comment gives context or warns about something non-obvious. A bad comment just restates what\u2019s already clear in the code.<\/p>\n<\/details>\n\n
\n  Isn\u2019t clean code just a matter of personal style?<\/summary>\n  
Not entirely. While styles vary, there are universally accepted principles \u2013 like meaningful naming, keeping functions small, avoiding duplication, and testing \u2013 that help any developer understand and maintain the code more easily.<\/p>\n<\/details>\n\n\n
\n  How do I start writing cleaner code?<\/summary>\n  
Start with the basics: use clear names, split big functions, avoid repeated code, use a linter, and write tests. You don\u2019t have to refactor everything at once \u2013 small improvements make a big difference over time.<\/p>\n<\/details>\n\n\n
\n  Should I refactor old code that already works?<\/summary>\n  
If you\u2019re never going to touch it again \u2013 maybe not. But if someone (even you) will need to maintain it later, refactoring is worth it. The later you do it, the harder it gets.<\/p>\n<\/details>\n\n\n
\n  When are comments actually useful?<\/summary>\n  
When they explain why<\/strong> something is being done, not just what<\/strong>. A good comment gives context or warns about something non-obvious. A bad comment just restates what\u2019s already clear in the code.<\/p>\n<\/details>\n\n
\n  Is writing clean code really that important?<\/summary>\n  
Yes. Clean code saves time for your future self and everyone else on your team. Code is read far more often than it is written \u2013 if it’s messy, updates will take longer and introduce more bugs.<\/p>\n<\/details>\n\n\n
\n  Isn\u2019t clean code just a matter of personal style?<\/summary>\n  
Not entirely. While styles vary, there are universally accepted principles \u2013 like meaningful naming, keeping functions small, avoiding duplication, and testing \u2013 that help any developer understand and maintain the code more easily.<\/p>\n<\/details>\n\n\n
\n  How do I start writing cleaner code?<\/summary>\n  
Start with the basics: use clear names, split big functions, avoid repeated code, use a linter, and write tests. You don\u2019t have to refactor everything at once \u2013 small improvements make a big difference over time.<\/p>\n<\/details>\n\n\n
\n  Should I refactor old code that already works?<\/summary>\n  
If you\u2019re never going to touch it again \u2013 maybe not. But if someone (even you) will need to maintain it later, refactoring is worth it. The later you do it, the harder it gets.<\/p>\n<\/details>\n\n\n
\n  When are comments actually useful?<\/summary>\n  
When they explain why<\/strong> something is being done, not just what<\/strong>. A good comment gives context or warns about something non-obvious. A bad comment just restates what\u2019s already clear in the code.<\/p>\n<\/details>\n\n\n\n
\n  Is writing clean code really that important?<\/summary>\n  
Yes. Clean code saves time for your future self and everyone else on your team. Code is read far more often than it is written \u2013 if it’s messy, updates will take longer and introduce more bugs.<\/p>\n<\/details>\n\n\n
\n  Isn\u2019t clean code just a matter of personal style?<\/summary>\n  
Not entirely. While styles vary, there are universally accepted principles \u2013 like meaningful naming, keeping functions small, avoiding duplication, and testing \u2013 that help any developer understand and maintain the code more easily.<\/p>\n<\/details>\n\n\n
\n  How do I start writing cleaner code?<\/summary>\n  
Start with the basics: use clear names, split big functions, avoid repeated code, use a linter, and write tests. You don\u2019t have to refactor everything at once \u2013 small improvements make a big difference over time.<\/p>\n<\/details>\n\n\n
\n  Should I refactor old code that already works?<\/summary>\n  
If you\u2019re never going to touch it again \u2013 maybe not. But if someone (even you) will need to maintain it later, refactoring is worth it. The later you do it, the harder it gets.<\/p>\n<\/details>\n\n\n
\n  When are comments actually useful?<\/summary>\n  
When they explain why<\/strong> something is being done, not just what<\/strong>. A good comment gives context or warns about something non-obvious. A bad comment just restates what\u2019s already clear in the code.<\/p>\n<\/details>\n","protected":false},"excerpt":{"rendered":"Imagine revisiting your old project after months or even years. You open the code, feeling a wave of…","protected":false},"author":50,"featured_media":7555,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","csco_display_header_overlay":false,"csco_singular_sidebar":"","csco_page_header_type":""},"categories":[199],"tags":[700,699,692,694,701,698,695,702,697,693,696,274,703],"_links":{"self":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7550"}],"collection":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/users\/50"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/comments?post=7550"}],"version-history":[{"count":2,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7550\/revisions"}],"predecessor-version":[{"id":7635,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7550\/revisions\/7635"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media\/7555"}],"wp:attachment":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media?parent=7550"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/categories?post=7550"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/tags?post=7550"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}