How Can You Tell If Your Code Is Good While Learning?

Good code can be subjective, but the goal is to make it easy to read, debug, and update. When I was starting out, I used to think, 'How would I feel if a violent person was maintaining this code?' Haha! So, keep things simple, use standard conventions, and don't depend too much on AI to do it for you.

When it comes to code quality, the truth is, it's hard to tell right away. I've been coding for over 25 years, and even I struggle to know if a piece of code is 'good' immediately. You should check for certain metrics like no warnings, proper formatting, and good documentation. But the real test isn't until years later when you look back at it. If others find it easy to work with and maintain, then you did well; if it turns into a tangled mess, maybe not so much.

Building a tool to analyze your code is an excellent way to learn—totally a software engineering move! A good benchmark for judging your code is the '6-Month Rule.' If you open up something you wrote half a year ago and understand it instantly, that's good code. Remember, code is read way more than it's written, so clarity matters!

I had an old project that I picked up again after a few months, and thanks to good consistency and naming, I understood the flow without much hassle. If you can jump back in and feel comfortable with your code, that's a solid indication that the code quality is decent.

At the beginning, it's all about trial and error. If your code works as expected, that's already a good sign! Give yourself some time away from it, then revisit it to see if it makes sense. Good code should be readable and ideally self-documenting with clear names for functions and variables. And if you run an analytic tool without finding memory leaks, awesome!