Code style rules that are actually useful

Heiker - Jul 20 '18 - - Dev Community

Warning: The following is just a long rant about things I do that help me write decent code that works (at least on my machine).

Let's start with a few rules that I thought were just useless but they have some hidden value that some may appreciate.

Maximum line length of 80 characters

In the javascript ecosystem there is this wonderful tool called Prettier that does some magic to your code to make it, you know, pretty. Prettier sets the max length of every line to 80 characters, and at first I didn't give much thought into that. One day I decided to add some unit tests to a side project and I finded myself wanting to have a terminal always in sight so I could see the result of those tests while I executed them in watch mode, and something beautiful happened, suddenly I could have a decent side terminal window open side by side with sublime text and I could see the whole code of a function without worrying about horizontal scroll. That moment was magical.

Write functions with three or less arguments

A function that doesn't take any parameters it usually means that it does some side-effects. I try to avoid those. If it takes one parameter than it probably gives me something back, if it takes two than it means that is somewhat configurable, which is cool but is one more thing to remember about that function. Things get tricky when you add a third argument into your function, is in that moment when I have to be carefull because it could mean that the function is trying to do to many things. If the third argument is only used in some weird edge case than I just added it with a good default value and leave it at that.

But what happens when I have a function that needs three arguments and they are use frequently? Well, in that case I stop for a second and have a second look at that function and try to look for a block of code within that function that I can highlight and quickly think of a name, if I can do that then that part goes into a separate function.

In the inevitable case that I need four arguments or more, than I go back to one argument and make it and object called "options" or "data" and keep writing until I finish with the core functionality. If it's posible I write some helper functions that have some predefined combination of the "options" object to avoid the pain of calling the one with the long list of arguments.

Write short functions

How short? 25 lines. Why 25 lines? No particular reason, it's just an arbitrary number. The point of this rule is to have a way of knowing when to stop for a second and think about what I'm writing. Most of the time I realize than I'm trying to do to much in a single function.

To avoid long function I do what mentioned before, try to look for a block of code and give it a name.

A wonderful consequence of having a bunch of little functions is that I can compose complex functions by calling the little ones in a given order. And if I actually did everything right then I can reuse one of these little functions in another context of the application or, even better, another project.

Conclusion

Some rules are good. And also, I finally wrote a blog post. Woohoo!

Back to being serious. If you don't like this rules, that's fine. Make your own rules, at the very least you'll gain consistensy when writing code, others or your future self will thank you for that.

Epilogue/post-credits

Wow! You made it this far. Thank you for reading this. Writing improvised blog posts in english is not something I do very often so if you find something wrong, let me know.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player