Don't have a 'common' library!
I've seen this in a lot of bigger code bases. There are multiple projects that share functionality. For example a solution with web and cli interface. Typically this shared functionality gets shoved into a library called 'common'. It does sound like a good idea at first but it can get very messy after a while.
Here is the problem: Programmers are lazy and creating a new library is painful. So everything that is or just seems to be shared functionality will end up in the 'common' library. After a while this library will be big and bloated and probably will have lots of dependencies on its own.
Let's imagine you need to implement a new client, say for Android. This new client needs only some of the functionality of 'common'. This means including 'common' and all of it's dependencies. More code means more bugs and more things that can go wrong.
A better approach is to have multiple smaller libraries with a defined very specific scope. That way it is easier to reuse only small parts of the overall functionality. As for the pain of creating new libraries: This can be automated to a degree.
Bottom line: Keep things small and simple for best re-usability!
When trying to incorporate some ideas of functional programming into my Python code, I tend to end up with lots of parameters in my functions.
Some questions to myself:
Benefits of using pure functions:
Ways to address too many arguments:
It is very hard to change the data structures in functional languages because of the ripple effect.
def a(data): b(data) c(data)
data would mean changing three functions.
Testing XPath in Firefox:
F12to open the developer tools
“If you don’t make experiments before starting a project, then your whole project will be an experiment.” - Mike Williams (Creator of Erlang)