Hello,
I was wondering is it a problem if I only understand code when I debug? Always when I get some kind of project I try to read project, but if methods is not in English language, code isn't commented at all and methods could contain more than 1k lines I get frustrated and miss stuff(lose info)... But when I try to debug it I am having a bit stronger picture overall, but still not full. I am asking this question because its my first job and I don't know what are GOOD PRACTICES to read code.
Debugging through code is a great way to learn about the internals of a code base.
Bad code is always difficult to read, especially if it is not commented, the variable names are not descriptive and the methods are huge.
You can also draw diagrams and walk through parts of the code in your head to see if you are getting it.
Knowing how to properly use a debugger is a strong asset to have (many senior programmers don't know how to do so properly). However, all such tools are best when used in moderation.
As it stands, it sounds like you are beginning to use the debugger as a crutch instead of working at being able to understand code just by reading it. Ideally, you will want to strike a balance between both approaches.
Learn to read code at a high level so you understand the basic idea or intent. Then using a debugger will help to flesh out the specific implementation details.
"...if methods is not in English language, code isn't commented at all and methods could contain more than 1k lines..."
Then i would even did not try to understand such code. The only place for it is trash bin.
If you have methods with 1k lines, no wonder you don't understand !!
The developers of these are following very bad practices !
Little people could understand this code...
Maybe my best advice would be to switch to a different project.
If you can't get out of this project, and if you can modify existing code (beware if you are new and junior, it is very easy to cause many regressions that will make you look bad) ...
then you have to follow the path of refactoring.
Refactor the existing code to make it more understandable.
Nowadays, the tools (Example : Eclipse for Java) can do safely many refactorings for you, the others you will have to do by hand.
"Extract method" is a great way to break huge methods into reasonably sized and meaningfully named methods.
If only debugging helps you better understanding, the code is in really bad state. A better idea would be to refactor pieces of the code you already understood into small functions and give them good names. This way, you can bring down those 1K line functions to a size one can understand. But beware, this might not be an option, you should have enough tests available to make sure you do not break anything, and you should be sure that you understand what you are doing.
But when I try to debug it I am having a bit stronger picture overall, but still not full.
That's entirely normal. It is very hard to get the full big picture of an application from the code alone. That's what documentation (vision statement, requirements, architecture, design) is for.
As others have said, debugging is a great way to learn, not only how code written by other people works, but also to understand how your own code really does work (which is often different to what you expect).
One caveat: the act of debugging necessarily "alters" the environment in which your code runs, so debugging is not the only thing you'll need. You will also need logging to collect metrics so you can analyse what happens when your code runs in non-debug mode.
Debugging is a start, but you definitely have problems on your hands if you have such large methods. If possible, try to get this code into a test harness, there's usually something from the xUnit family that could help (you didn't mention which language, so I didn't recommend a specific tool). Try to write some simple tests to check the behaviour of your code. Once you have it under test, you can start to refactor it.
I would say without understanding proper debugging techniques and delving into it, you will never become a coding guru or a great programmer.
We programmers love to debug the code. Consider for a moment that there was no such thing as bug, you would have left this boring field of programming !
All the suggestions made so far are good....
Typically what I have found is that as you gain experience in programming, you will be able to see code in blocks, recognize patterns and what certain sections are doing, etc without a verbose explanation or explicit commenting - it's why experience is so valuable -does that mean you should not do those things - no, it does not.
Does it also mean that it is a good practice to have 1K methods etc... well... it depends... really it does - in most cases this is a bad practice, but there may be some exceptional circumstance where this is warrented in your project - and in such circumstances debugging is a good way to interpret the methods, etc.
I would suggest though, if you are working in a team and there is a lack of commenting, etc then there is quite a bit of room for improvement as a team. Be careful though not to isolate yourself from the team - research any suggestions fully before taking them to your team leader - see it as an opportunity to learn from.
I suggest you get hold of the following books:
1) Working Effectively With Legacy Code by Michael Feathers
2) Clean Code by Robert Martin
Read them both, then give the second one to whoever wrote the original code and force them to read it, at gunpoint if necessary.
edit Once you have done that, read Refactoring by Martin Fowler and rework the code into something comprehensible.