Throughout the years, there have been many programming styles and fads. However, FP has proved quite resilient and is of great interest today. Why would you care to use FP? The question should rather first be, What do you want to get? and only then Does FP get you that?
We can certainly agree that the following list of concerns are universal. Our code should be:
- Modular: The functionality of your program should be divided into independent modules, each of which contains what it needs to perform one aspect of the program functionality. Changes in a module or function shouldn't affect the rest of the code.
- Understandable: a reader of your program should be able to discern its components, their functions, and understand their relationships without undue effort. This is highly correlated with maintainability: your code will have to be maintained at some time in the future, to change or add some new functionality.
- Testable: unit tests try out small parts of your program, verifying their behavior with independence of the rest of the code. Your programming style should favor writing code that simplifies the job of writing unit tests. Also, unit tests are like documentation, insofar that they can help readers understand what the code is supposed to do.
- Extensible: it's a fact that your program will someday require maintenance, possibly to add new functionality. Those changes should impact only minimally (if at all) the structure and data flow of the original code. Small changes shouldn't imply large, serious refactorings of your code.
- Reusable: code reuse has the goal of saving resources, time, money, and reducing redundancy, by taking advantage of previously written code. There are some characteristics that help this goal, such as modularity (which we already mentioned), plus high cohesion (all the pieces in a module do belong together), low coupling (modules are independent of each other), separation of concerns (the parts of a program should overlap in functionality as little as possible), and information hiding (internal changes in a module shouldn't affect the rest of the system).
So, now, does FP get you these five characteristics?
- In FP, the goal is writing separate independent functions, which are joined together to produce the final results.
- Programs written in functional style usually tend to be cleaner, shorter, and easier to understand.
- Functions can be tested on its own, and FP code has advantages for that.
- You can reuse functions in other programs, because they stand on their own, not depending on the rest of the system. Most functional programs share common functions, several of which we'll be considering in this book.
- Functional code is free from side effects, which means you can understand the objective of a function by studying it, without having to consider the rest of the program.
Finally, once you get used to FP ways, code becomes more understandable and easier to extend. So, it seems that all five characteristics can be ensured with FP!
Note
For a well balanced look at reasons for FP, I'd suggest reading Why Functional Programming Matters, by John Hughes; it's available online at www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf. It's not geared towards JS, but the arguments are easily understandable, anyway.
However, let's strive for a bit of balance. Using FP isn't a silver bullet that will automagically make your code better. Some FP solutions are actually tricky — and there are developers who show much glee in writing code and then asking What does this do? If you aren't careful, your code may become write–only, practically impossible to maintain... and there go Understandable, Extensible, and Reusable out of the door!
Another disadvantage: you may find it harder to find FP–savvy developers. (Quick question: how many Functional Programmer Sought job ads have you ever seen?) The vast majority of today's JS code is written in imperative, non–functional ways, and most coders are used to that way of working. For some, having to switch gears and start writing programs in a different way, may prove an unpassable barrier.
Finally, if you try to go fully functional, you may find yourself at odds with JS, and simple tasks may become hard to do. As we said at the beginning, we'll rather opt for Sorta FP, so we won't be drastically rejecting any JS features that aren't 100% functional. We want to use FP to simplify our coding, not to make it more complex!
So, while I'll strive to show you the advantages of going functional in your code, as with any change, there will always be some difficulties. However, I'm fully convinced that you'll be able to surmount them and that your organization will develop better code by applying FP. Dare to change!