I am a budding software engineer (now a sophomore, major in CS) and I really struggle to understand other people's programs. I want to know if this skill (or lack of it) can be a handicap for me, and if yes, then how can I develop it?
1Do you feel you understand code when it is explained to you as well or are you just learning by trial and error?– JeffOJan 9, 2017 at 18:44
1Why is this tagged 'coding style'? Is the reason you're having trouble reading code because it is poorly formatted? Ability to read code does not mean you need the ability to understand very poorly formatted or obfuscated code. Run the code through a formatting tool first if it helps.– BrandinJan 9, 2017 at 18:57
Just read an article this morning that reminded me of this question. Why working on Chrome made me develop a tool for reading source code– Eric KingJan 10, 2017 at 15:56
This is a great question! I had a follow-up question: if you work primarily by yourself on your own code (e.g. as a scientific programmer on a small project), how do you find good code to read? This has been asked before: softwareengineering.stackexchange.com/questions/69892/…– GauravJan 16, 2017 at 19:04
1Possible duplicate of What is the single most effective thing you did to improve your programming skills?– user22815Feb 1, 2017 at 22:57
It is essential.
The way you develop it is by writing your own code (lots of it), and yes, struggling through reading other people's code.
The problem, of course, is that not everyone thinks the way you do. I was in a first-year Java class a long time ago, and we were given an assignment. Contrary to what I believed (which was that the answers would converge on three or four common solutions), everyone in the class had a unique solution to the assignment.
It follows that you should be reading good code.
This is one of the reasons that Design Patterns have become so popular, and why you should study them. Design Patterns provide a common vocabulary for programmers to communicate with, and tune your mind for "better" ways to solve computing problems.
You should also study algorithms and data structures.
Corollary: You should always be striving to write code that other developers can readily understand.
7Corollary: Start simple by striving to write code that you can readily understand :-) Jan 9, 2017 at 19:39
4Generally a good answer, save for the part about patterns. Most of the GoF patterns (which is what people think of when you use the term) are over-engineered, far too fine-grained, far too OO-focused or just plain anti-patterns. And then folk turn up here asking which of these patterns they should use for their solution. Please, never advise devs waste their time with patterns. Jan 10, 2017 at 7:20
For small problems (say, reverse the numbers in a list), possible answers should converge to a small number of possible solutions. Good assignments should require solving many such problems and arranging the solutions to those problems in some way, so the total number of possible solutions to the assignment will grow very quickly.– BrandinJan 10, 2017 at 10:59
It is very important.
Once you graduate and get out into the world, most projects that you will work on will already have code contributed by others. Lucky is the programmer that gets to spend all their time on greenfield projects!
It is a skill that is acquired through practice and patience, and in many cases, it's a skill that many people don't really get much opportunity to work on until after they graduate and get that first job. Relax!
(although if your school has a co-op program, that would give you pre-graduation experience to working on large projects that are mostly written by other people AND it gets you academic credits! Something to look into, if it's available)
It's a major skill, depending of the specifics of where you work, it could even be more important than writing code itself.
As other skills, practice makes perfect! Try to read other programmer's code, debug it and what helps me personally, it's to refactor or improve small bits of code and expand from there.
Also, getting to know a open source project you use and try to understand how the inner code works can be helpful– RMalkeJan 9, 2017 at 18:43
There are distinct skills in both reading and writing code.
- One is syntax. Knowing what a method declaration looks like.
- The other is intent. Knowing why the method is there and what purpose it serves.
As for reading vs. writing. Yes reading is essential.
A few maxims that help many of us with that are:
- Code is read 10 times (at least) for each one time it is written.
- Someone else's reading the code is often... me in the future reading the code.
- I wouldn't defend my code style from more than 1 year ago, it has improved since then.
OK. So that's all great. Now down to what you're probably experiencing.
omg, this freaking huge codebase with tens of thousands of lines of source code and classes that are hundreds of lines long with crazy dependencies and every time I try to follow something I have to keep 10 levels in my head, etc, etc.
Sound familiar? Yeah. Deep breath. Relax. It's normal. It's what production systems are made of. People survive (and florish) in these seemingly incomprehensible situations because:
- tests (hopefully) exist and they also help document the system.
- programmers pair and often it brings more than double the result.
- good programmer get good at saying they don't understand until they do.
- changes are frequently just one or a few lines of code helping to isolate what to test
- code bases take months and even years to become familiar with
And finally, good programmers write meaningful commit messages when committing changes into source version control systems. (Feel free to add to answer)– rwongJan 10, 2017 at 5:51
Most of these answers focus on the importance of code reading to self-improvement. I wholeheartedly agree with and endorse it.
There is another angle to beware of - even if you were a prodigy who could not benefit from reading other approaches (impossible, but for the sake of argument....), you would still need to know how to read code because of a concept that basically doesn't exist in the university setting: the vast majority of industry projects are brown field projects (i.e. either in or integrating with a pre-existing codebase).
The need to read code just to understand the existing codebase and processes is real. It is always possible to ask another developer questions about code, but this can only take you so long. People leave, switch projects, or time just plain passes. The low-level details fade from memory and maintenance programmers apply patches. At some point, there is no single source of truth except the code itself.
Good code hygiene, style guides, code reviews and documentation help, but at some point the code is the source of truth for what happens and the only way to find the answer will be to go get it yourself. Aside from its uses in self-development, the ability to read code is a distinctly separate skill from writing it.
Understanding other's code is something which you can not escape as you will be most likely working in team even if not in team you will google different stuff and you will have to understand sample code. So yes it is a must.
What I feel is that everyone gets that feeling may be some less than other specially at starting, you understand your code better than others code as you spend much more time with your own code than someone else code as you not only read but write and structure it in your mind. If you start spending more time with other's code and first try to see what kind of structure/flow is being used, this will certainly make you understand the code better.
To make my point even more convincing if you have some code which you have written one year back, try to understand it again and I can tell for sure you will take more time but less than other's code as you have idea about how you structure your code.
Hope this help, don't get disappointed it's perfectly normal. Spend more time with code and you will eventually get it.
Well, I've just been given a project with about 100,000 lines of code written by a team in a different country, and I have to make some very significant changes to a copy of their code over the next months, while leaving as much code in common as possible.
You tell me how I can do my job without the ability to read other people's code, fast. If you can't read other people's code, you are completely, utterly stuck.