Clean Code Tip: Methods should have a coherent level of abstraction
Don't let the reader get lost in the code details!
Don't let the reader get lost in the code details!
DRY is a fundamental principle in software development. Should you apply it blindly?
In case of unmanageable error, should you return null or throw exceptions?
Good unit tests have some properties in common: they are Fast, Independent, Repeatable, Self-validating, and Thorough. In a word: FIRST!
Duplication is not only about lines of code, but also about data usage and meaning. You should avoid that kind of duplication.
Should you write your tests with the same care you write the production code? Of course you should! But what does it mean?
Having too many 'using's, or imports, is a good indicator that your class does too many things. You should work to reduce the number of dependencies of a class.
Is it true that we should always avoid comments in our code? In my opinion, no: let's see when adding comments is not only good but necessary.
The most important trait of Tests? They must be correct. The second one? They must be readable. The AAA pattern helps you write better tests.
Mental mappings are a good way to write shorter code that you, and only you, can understand. Prefer clarity over brevity!
Following a coherent standard, even for parameters order, helps developers when writing and, even more, reading code. How to do that?
When a function has too many parameters, it's clear that something is wrong. But... why? What are the consequences of having too many parameters?
Smaller functions help us write better code, but have also a nice side effect: they help us to understand where an exception was thrown. Let's see how!
Smaller functions help us write better code, but have also a nice side effect: they help us to understand where an exception was thrown. Let's see how!
Two of the operations you often do with your code is to discuss it, or perform a search over it. So using good names will help in both situations.
The Principle of Least Surprise is a simple principle that helps you writing clear, obvious code: this helps other developers foresee what a component does without worrying of unexpected behaviors.
Choosing meaningful names takes time! Time spent finding good names is time saved trying to figure out what you meant.