▲ | vivzkestrel 3 days ago | |||||||
I am really bad at reading code to be honest (especially other people's code). Any tips on how I can go about becoming good at this like starting from baby steps? | ||||||||
▲ | Night_Thastus 3 days ago | parent | next [-] | |||||||
Practice, context and domain-specific knowledge. #1 is easy, #2 requires some investigation, #3 requires studying. If you're looking at say, banking code - but you know nothing about finance - you may struggle to understand what it's doing. You may want to gain some domain expertise. Being an SME makes reading the related code a heck of a lot easier. Context comes down to learning the code base. What code calls the part you're looking at? What user actions trigger it? Look at the comments and commit messages - what was the intention? This just takes time and a lot of trawling around, looking for patterns and common elements. User manuals and documentation can also help. This part can't be rushed - it just comes to passing over it again and again and again. If you have access to people very familiar with the code - ask them! They may be able to kick start your intro. #1 will come naturally with time. | ||||||||
| ||||||||
▲ | lukaslalinsky 3 days ago | parent | prev | next [-] | |||||||
Read code, read code, read code. You will get better. When looking at a piece of code, keep asking questions like: what does this return, what are the side effects, what can go wrong, what happens if this goes wrong, where do we exit, can this get stuck, where do we close/save/commit this, what's the input, what if the input is wrong/missing, where are we checking if the input is OK, can this number underflow/overflow, etc All these questions are there to complete the picture, so that instead of function calls and loops, you are looking at the graph of interconnected "things". It will become natural after some time. It helps if you read the code with some interest, e.g. if you want to find a bug in an open source project that you have never seen the code for. | ||||||||
▲ | ivanjermakov 3 days ago | parent | prev | next [-] | |||||||
For me the trickiest part is getting how code is interconnected (class composition, abstraction with functions, module dependencies, etc.). Code navigation should be instant and effortless. Get good tooling and train muscle memory for it. | ||||||||
▲ | gerad 3 days ago | parent | prev | next [-] | |||||||
When you're debugging issues, read the code for the libraries you're using before going to their documentation. It's a great way to get exposed to other people's code. | ||||||||
▲ | aeturnum 3 days ago | parent | prev | next [-] | |||||||
I find it useful to open the code in an editor and make running notes in the comments about what I think the state should be. As long as the code has good tests you can use debugging statements to confirm your understanding. As a bonus you can just send that whole block of code - notes and all - to a colleague if you get stuck. They can read through the code and your thoughts and give feedback. | ||||||||
| ||||||||
▲ | danielmarkbruce 3 days ago | parent | prev | next [-] | |||||||
Use an LLM. It's not a joke answer. This entire article is silly. LLMs are great for helping you understanding code. | ||||||||
| ||||||||
▲ | __alias 3 days ago | parent | prev | next [-] | |||||||
It's far easier to read diagrams then it is to read code. To get a good mental model, I'll often get an LLM to generate a few mermaid diagrams to help create a mental model of how everything pieces together | ||||||||
▲ | hashbig 3 days ago | parent | prev | next [-] | |||||||
Like everything else, practice. I like to clone repositories of open source tools I use and try to understand how a particular feature is built end to end. I find that reading code aimlessly is not that helpful. Try to read it with a goal in mind. When starting out, pick a tool/application that is very simple and lean on LLMs to explain only the bits you don't understand. | ||||||||
▲ | maxverse 3 days ago | parent | prev [-] | |||||||
You're not alone! |