How do programmers find the correct files and lines of code to edit in an open source project when they want to add or improve functionality.
In: 58
Documentation and reading the code itself. Most professional programmers are able to follow the logic and control flow through someone else’s code.
This depends on what your level of expertise is. If you’re not a programmer, and wonder how programmers do their job, then the answer is that source code is like text of instructions for a computer to execute. Programmers read that text, understand it (to the best of their ability), and modify or add the extra instructions.
It’s like a recipe: if you want to change it, you have to understand its instructions first. Adding, or improving it, boils down to (pun intended) editing the text to specify more ingredients, add/change more instructions and so on.
If you’re more advanced, then one could interpret your question as which lines of code are correct (as in an adequate, or the best possible way) to change vs which ones achieve the same goal, but are a sub-optimal, or even harmful to the software/development?
The answer is – more often than not, programmers don’t do that. The goal, of course, is to have a piece of software, that is fast, reliable, and easy to develop+maintain. But programmers often do not think too far ahead, or don’t see the bigger picture of the project, so what seems to be the “correct” approach initially, could be a bad one later on. Take a look at the beginning of this question on Quora: [Why does Google internally overwhelmingly use its own in-house developed software and nearly no externally originated opensource or proprietary software?](https://qr.ae/pGdsIK) Pay special attention to the assumption that quality of code at Google is about the same as in most open-source projects – non-existent.
As someone who has worked about ~10 years in software development, I can testify, I have never seen a software project that didn’t suck. Except (maybe) one. I can’t even say I’ve ever worked on a personal project that didn’t suck, because I have often looked back at code I wrote way back, and cringed at it. Code I’ve written with the best of my intentions and knowledge, only to despise it, because I’ve grown as a programmer since then. I could say that some of my most recent work should foot the bill of good quality code, but… it would be a precedent.
You could read the code or documents, which are hopefully somewhat organised, or you can track down other people who are working on it and ask.
Not sure why nobody mentioned experience here.
If you frequently change projects, those projects won’t be particularly expansive so it’s easier to navigate.
If you rarely change projects, while those are huge you’ll become sufficently familiar with it so that you can navigate the sources from experience.
Hopefully they documented it well and wrote clear code (descriptive file/variable names, clear structure, etc.). If not, the OSS probably isn’t going to get many contributors.
Discord is also great for this. It used to just be forums, but most OSS these days have Discord servers were you can hop on and the devs are usually more than happy to help point you in the right direction.
Change something.
Does it break the bit you’re interested in?
Yes – Ctrl+z
No – Ctrl+z, change something else.
By looking for it. There’s not a lot else to say.
Suppose you want to do something simple like fix a typo. You can just search for the typo, and there it is.
Suppose you want to add a new feature. You would probably look for a similar feature. For example, if I’m at Google and I want to create video search, I could look at how image search works, and try to copy it. If there is no image search, only normal search, then I get to figure out how to create it.
This is complete guess but in most coding languages, you can insert comments that are ignored by the program, but can be read by anyone looking at the source.
A good programmer will make comments after each line or section of code and define what it does, options, typically outcomes, etc
So, one can start by looking for something that you know is there, that is related to the problem you are trying to solve, for example, suppose you are getting an error message. You can find where that error is generated using a search program such as grep:
grep -i “some error” -R .
(“-i” means it does a case insensitive search, -R means that it looks through my file system recursively, and “.” is the current folder where it is going to start).
It does not have to be an error that you start with – it might be a message in the user interface, or something else that you know exists and is related to what you are going to do.
Once you have found somewhere that you know is doing that one thing, you can open it up in a fancy text editor called an IDE (stands for Integrated Development Environment). This will normally do things like syntax highlighting (to make the code easier to read), and let you jump from some code that calls a function, to where that function is defined (the one I use lets me hold down control and click on the function name).
One then thinks through what the bit of code is doing, and via jumping to the other bits of code that it uses, or that use it (the IDE should have a way of finding things that call a function, too), then you can hopefully find the bit that you need to change.
Sometimes one can put in break points, that make the program stop running at the line of code that you put the breakpoint on. You can then see what the values of the variables are at that point, and see what function called the one that you have stopped the program from running at, in a big call tree. That also helps to find out how it all works together.
Start by finding the function by searching all the code. Then read the function’s code to understand how it works. If necessary, go look at the code for functions called by the first function and repeat until you found the bit you want to change. Smaller changes are easier.
Latest Answers