-
Typescript perfect sync – 3 tricks to keep it tight
Typescript perfect sync can be kept using couple of strategies. Most of us start with simple union types, like this: const ScenarioStatus = 'success' | 'fail' | 'error' | 'other'; So far so good. That works great… until you need to iterate over those values for rendering, validation, or other logic. And now You are stuck with two separate definitions: one array for logic, and one string union for the type. Sooner or later, they’ll fall out of sync and provide headaches to people. You could go for en enum…. Below behold the three TypeScript tricks to make your code tight, hard to break, cleaner, safer, DRYer and resistant to…
-
Statics VS AI code analysis ~13 tools
Statics VS AI code analysis works best using the pros from both words. Go hybrid ! Static tools understand the syntext, hardcoded parameters and are very strict. On the other hand AI understands context, can figure out business logic, adapt the codebase. Logic flaws or performance bottlenecks rule-based scanners might miss, AI will put more effort into that. Static analysis limits Static tools scan for syntax errors, style violations, and basic security patterns using fixed rules. Always consistenst, very fast but might generate false positives, ignore business logic, and require manual rule overrides. How often did You use @typescript-error 🙂 Do You code for the linter to pass, logic to…
-
Lauers Law – why less code is better
Lauers Law – why less code is better as a very solid idea. Just remind Yourself about all those DTOs that could be a simpler one with a mapper or a dedicated if-else-tree somewhere around data transformation. It challenges developers to prioritize efficiency and elegance in their coding practices, ultimately leading to cleaner, easier to understand and more maintainable systems. The Essence of Lauer’s Law At its core, Lauer’s Law emphasizes that reducing the amount of code can lead to better outcomes. The principle suggests that if developers had twice as much time, they could create a system with half the code while maintaining or improving its quality. The idea…
-
The philosophy of unix – 9 commandments
The philosophy of unix is a guideline of standards and software design & philosophy approaches : Elaboration : The philosophy of unix is a universal approach to any development, not only software 😉
-
Universal Principles of Design: Third Edition
Universal Principles of Design: Third Edition OverviewThe Universal Principles of Design, Updated and Expanded Third Edition is a comprehensive design reference book authored by William Lidwell, Kritina Holden, and Jill Butler.Original was released on February 7, 2023, the third edition expands its predecessors by 75 new entries, bringing the total to 200 principles, laws, and guidelines essential for effective design across various disciplines. It serves as a guide for anyone looking to enhance their understanding of design principles that can be applied universally in professional and private life. If You want to learn more for free go HERE !! https://principles.design/ Why should care ? Overall the book Universal Principles of Design: Third…
-
Chestertone`s Fence in coding and not only
The Chestertone`s Fence in coding is the principle named after the writer G.K. Chesterton. Serves as a critical reminder in programming and software development: before removing or altering existing code, one must understand why it was implemented in the first place. This principle is universal for life. Emphasizes the importance of historical context and the potential consequences of change, especially a quick and fast one. Urging developers to approach modifications with caution and respect for prior decisions. Even if they are unknown or seem meaningless. Understanding the Chesterton`s Fence Chesterton`s Fence principle, at its core, suggests that every piece of code, no matter how outdated or unnecessary it may seem,…
-
A Philosophy of Software Design by John Ousterhout – review
A Philosophy of Software Design by John Ousterhout is a great book. Period. I would say that it is a great additional to reading Clean Code. Clean code in my opinion is dry and very… strict ? Not much room to fiddle around with rules set by Uncle Bob the Guardian of the Clean Code. John Ousterhout provides us with a more kind and flexible approach without strict, dry rules to follow. Since the book was wrote by a professor at Stanford that had classes it might get a bit technical when John goes through the different code sets but it does print a better picture of the whole problem.…
-
How to write code – part 1
How to write code ? Writing Code for Future Comprehension. How to write code In the „fast-paced” world of software development is a very tricky question… The ability to „write code so in one year you or anyone else will be able to easily understand what it is about” can be a crucial skill. This practice not only enhances the longevity of your projects but also significantly improves team collaboration and code maintenance. Gives a lot less headaches also. Let’s explore why this approach is essential and how you can implement it in your coding practices. As always.. take a grain of salt with a dose of common sense… The…
-
How to judge code – part I
How to judge code is a tricky question. With all the clean code rules, KISS, DRY, YAGNI, SOLDI and so on and so forth one can go crazy and question ones sanity in the end. What i wanted to throw out there is to judge the code be a very simple rule the encompasses multiple different one, is not straightforward and is very flexible. How to judge code ? Judge the code by how easy it is to debug We all know that one person at a company that knows all the quirks and secret sauce of a language, pipes, default interfaces and so on…. that person also knows the…
-
Locality of Behaviour
Locality of Behaviour is a great principle that should help with maintaining the code. This is the characteristic of the code that enables a developer to only read a small portion of code to understand its function. Without the need to skip, skim, read, jump all over multiple files. I love that rule cause it DOES MAKE SENSE. I can see many places where we would benefit from it but not always do it that way because of the 'standard’. Which, in the end, nobody knows what it is anymore cause everyone is mixing patterns, antipatterns and the number one performance metric is how fast you can deliver… maybe i…
