Hey! I was wondering about reading source codes of libraries that you may use on a daily-basis.
Like, if I decided to learn React and Redux, it's ...
For further actions, you may consider blocking this person and/or reporting abuse
It's going to depend on the maturity of the source code libraries and the extent to which you utilize them within your own code.
Personally, I almost never read through the source code when I first start out with a library if it's well established. I'll use it for a project, read through the documentation on how to use it and integrate with my system.
When I do take a dive into the source code, it's generally because there's a bug or some non-standard behavior that is occurring and i need to walk the stack to figure out if it's my code or the library.
But reading through the source code for a well established library just so you understand how to use it is probably overkill assuming they've got some decent documentation or examples.
It does make sense to start reading through the code if it's a less well known library, or something that may be untrusted, or it does things and you want to figure out how it was done, or if you're curious about how they've structured their code. There are lots of good reasons to spend the time peeking under the hood, but it's generally going to be overkill if you just want to be able to use some of the basic functions stored in that library or framework.
This -- documentation exists so you don't have to read the source.
When I work on any project, I have a phrase in my mind that I confirmed in time "Learn to reinvent the wheel, but don't reinvent it". If I know how everything works under the hood, skip over spending time on this. If I don't know how to use it / make it, I'm going to make it for the first time from scratch. After this, if I have an opportunity to get over it, I'll use it.
"Reinvent the wheel" is a funny phrase when you consider just how many times we literally have had to reinvent the wheel (compare and contrast: stone wheel, bike wheel, car wheel, ATV wheel, airplane landing gear wheel....). We absolutely need to know how to reinvent the wheel, otherwise we'd all be rolling around Flintstones style still.
That said, we should only be reinventing the wheel if (a) existing wheels don't meet our current needs, and/or (b) we have a specific original improvement in mind that will make the wheel better in a given use case. That, of course, means we have to know a lot about the wheels that exist. Ergo, your reason for reading source.
Best to consider refactoring before considering rewriting/reinventing, IME.
Depends entirely on the code base. Rewriting is usually much quicker than refactoring someone else's spaghetti.
I'm advocating considering refactoring first, not saying it is always the answer.
I read source code a good bit. I often look at a library's source code because I want to make sure it operates under the constraints I assume that it would. Otherwise it could affect how I call the code. (IMO, this is not a good sign when I need to know how it works to make sure I use it properly. Yet I need to do that regularly.)
The last thing I recall really trawling thru code for was in ASP.NET Core. I was looking for what the
[Authenticate]attribute does precisely. I found code that I suspected was called, but never actually found a direct link from the attribute into that code. Yay meta programming.Anyway, you probably don't have to read the source code. The alternative -- if the documentation is not clear -- is to figure out how it works experimentally. Try using it different ways and see what happens.
Last paragraph is legit.
I do believe in reading source code for two reasons:
(1) You should understand any abstraction you lean on. (However, decent documentation usually removes the need to read the source, as iedaddy said).
(2) You learn a lot from reading code.
However, I don't have time to read it all. So, in the end, there are three situations that will lead me to read source:
SCENARIO 1: Epic code! I love reading code bases that I can learn a lot from. I especially enjoy combing through standard library implementations. Honestly, I want to start doing this more.
SCENARIO 2: Terrible code! If I want to learn why something is so unstable, inefficient, or otherwise terrible, I'll dive in and see what I can learn not to do.
Some people ask me why I prefer Clang over GCC. Reason #1, the source for GCC is some of the scariest cruft-ridden spaghetti I've ever read, while Clang is clean and modern. Which foundation would you rather build your house on?
SCENARIO 3: Important code! Whenever I'm working on a fresh implementation that is functionally similar to existing open source code, I'll often look at the original implementation to learn how it works. I'll also read the code if I rely so heavily on it, I need to understand how it works. (You should seriously consider this if your entire project's functionality hinges on one implementation of a library or algorithm.)
As a side note, there is no faster way on this planet to learn a programming language than to jump into mature source with nothing more than the project documentation and the official language docs.
Its a personal preference. If you are just trying to get through your day and develop against an open source library, then don't look at source code. But if you are intrigued and get excited about it, look at it. There is no right or wrong answer here.
If you want to take your programming language skills to next level, it is worth reading the source code. That's because library writers are usually very skilled at the programming language, design patterns etc.
Ofcourse, its not just reading, you have to figure out the patterns used and why the code has been written the way it is.
2 cents from my side.
I'm considering you're talking about using widely known libraries.
Extension: It gives you an idea on how it works, now it's quite easier for you to extend the library
Learning: It is written by experts, you'll get a lot to learn on how would you write the code (Design Patterns, Architectural Style, Optimisation)
Interviews: Believe me, when I share internals of how Java works or how Spring works, it gives an awesome impact on interviewer
Contribution: Rare scenario, but if you find any leak or bug you'll can sharing your inputs. Voilla!! You're an Open Source contributor.
Code Review: Congratulations!! You're awesome code reviewer, you know lot many standards as you've gone through em.
TBC...(Battery Low)
Just wanted to plug here Safia Abdalla's blog posts about Node.js internals as she reads the source code of Node.js core modules and shares her thoughts at blog.safia.rocks
Wouldn’t it vary most on style of learning?
I do it if the source isn't too big or if I have a problem. Often API docs are out of date or simply wrong.
Yes. Read the code of libs you use and of libs that do cool things you don't know how to do.