Have you ever had that feeling that your solution could be coded in less lines? Have you ever been stuck and can’t find a way out? The intent of today’s post is that if you find yourself in any of these situations, that you regain productivity. Here are a number of random tips that I picked up over the years.

Writing the keywords true or false
If you find yourself having to type the keywords true or false, you can probably refactor this to less code. Less is more when it comes to coding, but make sure it still expresses its proper intent. A great example of this is the following I see 99 out of 100 junior programmers do:

Clearly this can be refactored to.

Naming Classes
If you can’t come up with a name for your class, you probably need to reconsider your design. Does your class do too much? Stay true to the single responsibility principle, yet avoid over-engineering.

Use a thesaurus
If you code in English, and you are not a native English speaker (like me), a thesaurus can be useful at times for helping you find good names for methods or classes. Make sure you don’t pick words that just show off a good vocabulary; developers have a well developed BS-detector.

Avoid reusing constants in tests
Although tests need be refactored, and should be as clean as your production code – never write a test with a reused constant for multiple tests. I have seen this be the cause of bugs more than once. Keep your expected value within the scope of the test method. If you find yourself doing something like the code sample below, please refactor this back, you are setting yourself up for problems in the future!

Getting stuck
If you are stuck, explain the problem to someone else. Just the act of explaining the logic generally triggers the answer already. Even if you are explaining it to someone that doesn’t understand coding. I remember once reading that you should have a rubber duck on your table, to whom you can explain your problem to. I have little doubt this would actually work – Let me know if it worked for you, I have always had the luxury of other people around.

Repetitive Methods
If you find yourself having 3 or more methods having a very similar if or case constructs, you can reduce your complexity using a state pattern. Not only does this reduce your complexity but also makes your code naturally more extensible and testable.

The Rule of Three
Similarly, if you find yourself doing something very similar in a different context 3 times or more you can probably refactor this concept into a more reusable solution. This concept is known as the rule of 3. Stay DRY at all times!

Final thought
The intent of this post is to get triggered once you find yourself in one of these situations to help you be more productive, or avoid defects in the future. If you have solutions or triggers for situations to share, please let me know through the comments! I would also love to hear your ideas, and please also leave your comments if any of these principles worked for you for the near future!