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.
Top comments (6)
In the 90s I was a strong supporter of the 80 chars length rule.
Now I allow my team an myself to go up to 120, 'cause, you know, widescreens and high DPI. A longer line allows for better naming of vars and methods.
80 (120) chars are not only for screen width IMO
you can have a very long if clause or 9000 nested fuction calls. this limit implicitly hints you, when line becomes unreadable, despite still fittimg into modern screens. Another point on widescreens is that I have project structure on one side and Gradle tasks on another, so code section is still not so wide ))
overall most of these advices are more of a clean code rather than code style.
CS is more about curly braces on same line in method declaration, indents etc. I would recommend you Clean code, if you havent read it already, I’m sure you will like it )
That's fair. Meaningful variables names are important. I actually finded dificult to go beyond 80 characters in a statement, unless of course I'm chaining methods or creating an object with lots of properties.
I only really write functions when I want to de-duplicate code or unit test a specific few lines. Don't believe in using a function just to give a block of code a name, a comment can do that. When code gets very nested is another time I start using functions, so I'm not like 4 tab lengths in. Putting code in 10 line functions for the sake of it can actually kill readability as you have to keep navigating around the code-base to read.
Hasn't been a problem for me yet. Code is still fairly readible.
Guess I'm just trying not to repeat the mistake that I see in the legacy apps the I have to mantain at work. In the codebase that I deal with daily is actually common to see methods that have more than 500 lines, and that's just wrong. People are actually scare to touch one of those methods.
The goal is to write functions that anyone can read and have the confidence that they can change stuff, make it better, or delete the whole thing if it's no longer necessary.
100 characters because I have a widescreen, but otherwise agreed.