Tips

My personal tips and notes I collected for myself along my journey of being better developer

Zero Commented Code Policy

Zero Commented Code Policy

Reading Time: 2 minutes

This tip is based on Uncle Bob’s Clean Code book. Zero commented code policy is a way to manage your code base such as you must not have commented code. There are tons of discussions about it but the most solid argument is the commented code tend to rot. You probably never going to need this commented piece of code, and if you do, you probably will have to change it. There are two options related to commented code while you are reading the code:

  1. You won’t read it.
  2. You will read it, but this piece is not compiled or executed so you just leave it there to stink until next time you do those steps again.

Both ways are bad. You waist your time on code you are not using, so my advise is just delete it. This always reminds me of the YAGNI rule, You Ain’t Gonna Need It.

My best practice is to delete commented code whenever I see it in my code base, without even reading it. If something breaks in the future, just fix it.

Divide and Conquer

Divide and Conquer

Reading Time: 1 minuteAfter watching the great Building a From Library playlist by the objc.io guys I really understand the importance of continuously refactoring my own code. They start from a big monolith monster code base and start refactoring parts of it, a part at a time. It even sometimes seems as they make the code even more complex then it is by refactoring, but of course they take 1 step back only to then take 4 steps forward. This divide and conquer process is very satisfying in the end of it.

De Morgan’s Law Is Not Always Readable

De Morgan’s Law Is Not Always Readable

Reading Time: 2 minutesConsider the situation the you are checking if user could login to your application otherwise you should redirect him to login page. The user will be redirected to login page only if none of the following properties are true, or all of them are false:

user.active, user.sync, user.is_admin

Ok, so now logic starts to interfere, De Morgans law gives us the chance to write this condition in those two ways:

if not user.active and not user.sync and not user.is_admin:
    redirect(LOGIN)

or if we force the De Morgan law:

if not (user.active or user.sync or user.is_admin):
    redirect(LOGIN)

Think about it for a while and try to read both conditions and tell what condition makes your brain think more. For reading the second condition is much more difficult to interpret, the flow of reading this line makes your eyes go back and forth to understand in what condition should we redirect. The first line has a much declarative flow of reading, I read it from the beginning to the end without thinking too much about it.

Commit with Deficit

Commit with Deficit

Reading Time: 1 minuteThere is nothing more satisfying than adding a feature or making something broken work, and see that your commit has more deletions than additions.

Balance Between Productivity and Quality

Balance Between Productivity and Quality

Reading Time: 2 minutesAlways try to find the balance between productivity and quality. We all want to have the most clean and testable code, sometimes we rush it too much. Developers tend to forget that the code is the tool rather than the target of the business. Last week I found myself wasting a whole week learning a new architecture and programming style to finally achieve something I could write simpler and faster. Well calling it wasting is a bit aggressive, but I realized that I haven’t delivered any output.

Pros:

  • I have learned new technologies/frameworks/architecture/etc
  • My perspective on software engineering is now richer
  • My code quality would be better
  • I can understand code bases I couldn’t before

Cons:

  • Time
  • Productivity

Try to find the balance between those pros and cons, analyze your requirements and circumstances to deliver in time.

Don’t not not

Don’t not not

Reading Time: 1 minutePlease (PLEASE!) don’t use the following patterns for naming your variables or functions:

let not_logged_in or func is_not_admin() or $isNotAvailiable.

That’s because when one reads your code he/she has to interpret the login when there is a condition on the negative of those variables/function.

For example:

if not not_logged_in {
    /* if im not not logged in, then i am logged in */
}
....
$service = !$isNotAvailiable ? $a.service : null; // mind blown
...
etc.

Instead you can just remove the NOT word from naming, that’s much more readable and fluent.