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
Well, a good OSS project will have their source structured in a way that makes sense.
So it could be by layer (a folder for everything that does DB access, a folder for business logic, a folder for UI, etc.), by feature/components (a folder for the dropdown, a folder for the toggles, a folder for the cards, a folder for the router, etc.) And so on and so forth, but it is usually quite easy to get a grip on the organization and get a rough idea about where the change needs to be made.
Once you drill it down to a couple of files, the classes, methods and functions should have relevant names that help to find a good starting point to explore the code itself.
You don’t really need to find the entry point of the feature (i.e., the first bit of code executed for that feature), just something that’s probably executed most of the time the feature is used. From there, you can look at what calls and is called by it to pinpoint what you need to change.
Also, nowadays, most of the time, unit tests and documentation will help to find the correct file and function.
Generally a programmer will be able to read the code and work out where would be best to add in new functionality. Most projects are documented either in the code itself or in separate documentation, so it’s easier to find which bits of the codebase do what.
It can be difficult sometimes. If you’re taking the time to contribute updates, it probably means you use the code and get to know it.
Worst case, you have the code on your computer, open it in your development environment and run the code in debug mode. You can then walk step by step through the code while its running to see how it works.
A good code base will be organized. If you want to change something regarding the database the folder marked “Database” (or aliases thereof) is probably a good place to start looking.
If you’re lucky the project will have proper documentation which you can simply read and that will point you to the right direction.
If that doesn’t work but you know where the functionality is being used you can find those spots, see what functions are being called, and find where they are defined.
And if the worst comes to worst just do a text search for keywords you think will be relevant is always an option. There are only so many places that “database” or “db” or “select” can appear. Pick the right keyword to narrow things down, and manually check each match manually to see if it is what you need.
“Finding the correct lines” is then just a matter of reading the code and understanding what it does. Code isn’t just random symbols with no rhyme or reason: a programmer simply reads it and figures out what it’s doing, and from there decides on what needs to be altered or added.
It’s the same way someone would know how to find a document to send to their boss. Code is organized into projects & folders from which a developer who knows the codebase can quickly find the code.
In the instance that code is broken up between files (pretty common in modern program architecture) each file has a reference to the file it’s using, so you can just trace the code from the start until you find what you’re looking for.
Same way that you would find the right recipe in a cookbook. You’d know roughly where to look anyway (i.e. you wouldn’t be looking under roast dinners if you were baking a cake), you would expect it to be sectioned out nicely so you can find stuff, you could search through things if you needed to, and – with code – you can do stuff like load it into a development environment (IDE) and use its features to find the things you’re looking for.
That’s the neat part: we don’t!
Joke’s aside, while programming is a lot more subjective than one would think, there are still certain patterns and etiquette most people follow when writing code.
Even so, the codebase might be much bigger than you’d comfortably search in. So we use common text editing tools like “find word in whole project” to situate ourselves and, whenever possible, run the code in debug mode, which allows us to stop the execution at any point of the code and check what the program is doing at that point. Or at the very least write-in innocuous test commands that show up on screen so you can gauge where in the execution a certain function is called.
From that point, you can probably tell where in the code your new feature is supposed to go. Now, writing the new feature and not breaking anything is where only experience can help you. There’s no foolproof recipe that works with every code.
Greping for keywords helps — especially if there are decent comments. Knowing what to grep for is a tricky skill, though, too. Kinda like coming up with his words to search for in a web search.
That’s a good question.
How do we do it?
Like, damn. I’ve been contributing to a massive private project since I got my first real job 5 months ago and it’s friggin’ hard. And, I even have supervisors and seniors to ask questions to when I’m really confused. If this wasn’t literally my job, I probably would have given up in exasperation one week in.
[removed]
Latest Answers