Nice article of an important topic. But when it comes to readability of code there a lots of opinions.
I really like the concept of improving readability by breaking up the code in small well named functions.
Here is my stab at improving readability of the example under “Refactor with tiny, named…
Sometimes writing detailed descriptions of the code is useful. But it reduces the readability of the code, if there are too many comments interspersed with the code. The trick I follow is to document all the code at the bottom of the file. Near the variable or the function, give a doc identifier e.g. // <<ID_var00_12>>
Good tips. Also using functions not only increase readability, but a way to organize your thoughts. The only thing I will like to add is that writing readable code does not eliminate the need for writing good comments, which should be used to convey information that your code does not tell, such as the rationales of particular coding choices, the context surrounding, and etc.
Thanks for a well written perspective on TDD. I personally love TDD and do practice it daily at work. I feel some of your experience with it has been jaded by working with Sr. Developers who may not understand TDD. Watching some of the Bob Martin videos on TDD may help understand how it can be done effectively. The key is to work in very small steps…
First off, I think this is one of the much needed things to be continuously reminded of — writing code for reading instead of speed of typing. The only thing I would change is the example of handleSubmit — you broke a couple of the things stated previously. I have no idea what “e” stands for and there is that magic number of 2000.