Coding is fun for many developers and as coder you are guaranteed to not be bored, each year many new languages, technologies, frameworks and libraries emerge.
The coders are the central piece of a project, their contribution are very important and having good coders is a big guarantee to make a project a success.
But who can be qualified as a good coder, the one who code a lot in a reduced time?
Any developer know that more code implies:
- more bugs.
- more code smells.
- more support.
- more documentation.
Each line of code could introduces a problem in the codebase and increase its technical debt, and to have less bugs it’s recommended to have less code.
Let’s take as example the bubble sorting algorithm, some developers will needs 50 lines of code because they code it from scratch and some others needs only 2 lines because they use a known library to do the job.
What ‘s the big difference between coding from scratch and using a known and mature library?
A mature library has the following advantages:
- used by thousands of developers
- very well tested
- The evolution and the compatibility with many OS is guaranteed
- well optimized
- well documented
- maintained
A good coder must be a google friend and before coding a complex code, search if there’s no know library doing the job. In C++ as for other languages there are many interesting libraries like STL, Boost, POCO,…
During my experience as developer I discovered that a good coder is the one who code less and fast. and it’s not necessarily a guru who have a big technical skills. But the one who have the ability to search and choose the right library for the right job. Sometimes the technical gurus tend to code from scratch, which can be hamful for the codebase quality.
But how to Choose the good library?
Choosing a software library is not always an easy task, specially if many concurrent libraries exist for a specific need. Many factors could influence a developement team to choose a library, here are some of them:
1- Licensing
The library license is the first thing to check, it’s very important to verify if the license is compatible with your using in your project, before going further and discover the library capabilities.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2- Is the library satisfy your needs?
It’s a trivial factor, but how many devlopers realized a mini proof of concept to check that all their needs are satistified by the library. Sometimes we discover very early that the library is not good for some reasons.
3- The community is active
Many problems could occurs when using a library, if its community is active, it will be very easy to find quickly a solution.
4- What about the trend of using the library?
It’s interesting to know if the library grow on popularity or not? for that you can use google trends and discover the evolution of the library over years.
Here’s for example the trend of d3.js API:
5- Is the library has a break changes in the past?
Before adopting a library, take a few minutes and search in the web for “LibraryName breaking changes” to check if for a specific version a breaking changes was done.
It could help you for the following reasons:
– Avoid using library examples from older versions.
– it’s not good sign if a library has a big breaking change. It means the developers does not care about the library users, and it could happen again in next versions.
6- Constraints and limitations of using a library.
Sometimes a library is awesome for a specific needs, but has one killer limitation which could force you to not use it.
Let’s take as example the google chart api, it’s a versy useful chart library. However, it has one annoying limitation, the user must have an internet connection.
Before choosing a library, be sure that no limitation could affect its using, you have just to search in the web for “LibraryName limtations”.
7- Documentation
A well documented library will helps you considerably when you use it. specially if it contains many samples of using it.
8- Did you care about performence when using the library?
If you plan to use a library in a context where the performence is very important, don’t only trust the benchmarks found in the web. It’s preferable to make a POC with your specific constraints to have a better idea of how the library behaves in your specific context.
9- Is your application multiplatform?
If you application must works in many platform, don’t test mostly in one platform, after finishing the developement test for all the other platforms.
Always test from the begining on all the targeted plateforms, some libraries are very good implemented for an OS and very bad implemented for the others.
10- is there any other serious alternative to the library chose, and you have a doubt?
In some cases you could find two awesome libraries for the same needs, and you have a doubt of using one of them. In this case never let your code highly coupled with the library. Prefer using wrappers and facade patterns to isolate it’s use.
Of course there are many other factors that could influence your choice. and to minimise the risk of using a bad library which we must change it after. It’s always a good practice to isolate its use in some few places in the code, by using wrappers and facades.
Try to evaluate the coupling of your application with all the libraries used, identify the libraries highly coupled with your code, and progressivly try as possible to decouple its use.
Many tools could be used to detect easily the coupling of external libraries, we can enumerate JDepend and JArchitect for java, CppDepend for C/C++ and NDepend for dotnet.