how can i go from "code that works" to "good code"
Posted by Striking_Try_8763@reddit | learnprogramming | View on Reddit | 15 comments
I'm a sophomore in college who works on a lot of personal projects. Right now, I'm at the stage where I just write code with the sole purpose of making things work
- What differentiates "good" code from code that merely functions?
- Where can I get meaningful feedback on my personal projects?
- Is "just build more stuff you find interesting" actually the best learning path?
I hear experienced devs say that the best way to improve is simply writing more code and working on interesting projects, but are there more structured approaches?
DoctorFuu@reddit
Make it work,
Make it fast,
Make it pretty,
in that order.
I'm not an experienced dev (statistician). But to me, "good code" is code that:
- works
- is fast enough
- is easy to read and understand
- is easy to modify (either debug, add tests, add features ...) - is difficult to use improperly (if someone else is going to use the code for example, the way to use it should not be ambiguous). This includes code safety (but could be a separate point as well).
I generally don't have projects that are important enough to do everything. The first three I always do, the rest it depends on whether I plan to reuse the program in the future and how much time is realistic to devote to it.
Good code, clean code ...etc... is a common source of debate between experienced devs, there are different philosophies...etc... But I think the 3/4 first things I gave above are common to all of them. What they disagree on is mostly on how to translate these principles into the code.
IMO, the best way is to just keep building projects, noticing when what you write is causing you issues, and the next project you try to do things that avoids the issues you had in the past. If you are at a job with other devs, there will be guidelines about what is meant by good code in that company, so you learn there.
For personal projects, I would just give the advice to make it work, then make it fast enough, then make it pretty. (make it pretty is all the things that let you pick the project back up in two years without being in pain to understand what is going on. It should be smooth AF to get back into the code and modify it even if you had forgotten how it was written).
silly_bet_3454@reddit
You could check out the clean code book, but my recommendation would be to not even worry about good code until after you get your first job.
You learn the meat and potatoes of different technologies by just building stuff as you mentioned. It's only once you start contributing to a massive shared code base that code quality really matters, and that's also when you'd start getting good opportunities to get feedback ie. code review.
Anyway, the idea of good code is not that complicated. It means things like keeping the code organized, having clean abstractions, not having dead code, not having repeated code, having the code be self-documenting, simple, easy to follow. Good function and variable naming conventions, and so on.
thewrench56@reddit
I think that Clean Code might be one of the worst books for learning good code. It mentions mostly obvious stuff. It hardly talks about directory structure, or devops, or actual testing (I think testing might be mentioned when they argue for splitting stuff into modules).
I find bigger codebases are sometimes (maybe even often) worse than small code bases from senior devs. Simply because big codebases suck. They can't be cohesive.
Probably this is the hardest to get right. I doubt one can get this right. Your code always evolves and it will be too late to change your core abstractions. If you got it right, you are lucky.
Striking_Try_8763@reddit (OP)
okay thank you so much!
so I should just keep building and try to keep in mind the things about clean code you mentioned?
silly_bet_3454@reddit
I think so. When I work on personal projects I like to just do some basic things to keep the code looking clean, such as:
- eliminate/consolidate repeated code
- try to avoid functions longer than like 10-20 lines
- try to avoid files larger than a couple hundred lines
- keep the functionality well organized, eg. maybe you have a file with utils vs a file with the main server vs a file with some app specific logic
- avoid deeply nested code, like an if block inside an if block inside an if block. usually it can be better organized in terms of flow.
Hopefully these things are just intuitive and the result is the code simply is pleasing to look at and work with.
herocoding@reddit
Ask for feedback - let others review your code.
Read code from others, experiment with it, set breakpoints, or extract code-snippets and run and study it.
You would improve slower if you only see your code and apply your same coding-styles and coding-habbits again and again.
I like platforms like https://platform.entwicklerheld.de/challenge?challengeFilterStateKey=all where you see how others have solved a problem (after you solved&submitted it).
axiom431@reddit
Double check the syntax & logic flow.
NetSea3575@reddit
thats called refactoring..
JacobStyle@reddit
Some of the biggest differences between good code and shit code are how that code fares when the size of the project increases and how it goes when someone else tries to read it (or you try to read it months after not touching it, which is sort of the same thing). There are guidelines, sure, lots of great advice in this thread, but also a lot of it comes from experience, where you expand a project to a few thousand lines and see what works and what breaks, or where you look at your old code and scratch your head and vow, "never again" about a few things.
AlexanderEllis_@reddit
"Good code" is code that works and is easy for other people to understand when they're drunk at 2am, because a few months after you write something, it might as well be someone else's code, and you're gonna be happy you kept it simple. Everyone has their own standards so there's no single "best" definition of what good code is, but in general just try not to do unexpected things (the
check_date()function probably shouldn't be responsible for validating someone's login, for example), try to keep logically separate code visually separated as well (linebreaks, comments, whatever), put comments in confusing places that explain why the code does what it does rather than what it does, and name variables in ways that makes it easy to understand what it's for (current_timeandcheckout_timeare easier to remember and distinguish between thanctandcot, for example).4_fuks_sakes@reddit
Move magic numbers into constants with good names.
Add sanity checks.
Move checks to the top so that actions die as soon as possible. (Depends on what you are making)
Make sure variables have good names.
Unit Tests if it is hard to test that is a sign you are going down a slippery slope.
Clawtor@reddit
The larger your projects get the more they will benefit from clean code and the more you will see where to improve your code.
Also if you leave a project and come back to it how easy is it to get back into it.
Another thing you can try is to imagine explaining your code to someone. Or actually explain it to someone.
Good code should be easy to understand basically.
There are other criteria, like how easy is it to add to and how performant is it.
Also everyone thinks their own code is shit - you will likely go on a journey of over-fixing, over-abstracting but that is still valuable to learn from. I remember over-prioritizing performance for instance which led to very dense code. Also abstracting the shit out of my code which leads to code on one hand looks nice and fancy but is also hard to reason about.
EsShayuki@reddit
Make sure your code follows good principles: Efficient, resistant to errors, clear, logical, composable, expandable, and so forth.
The reason you want to "just build more stuff" is that you'll eventually learn first hand what the problem is when you don't follow good coding principles. Someone saying something isn't a very good way to learn. Running into serious trouble because of the way you coded and being forced to deal with the repercussions teaches you far better.
RookTakesE6@reddit
To a certain extent, functional = good, it's just that the bar for "functional" gets higher and higher. So one way to learn to write better code is to take on bigger challenges where "merely functional" is a higher standard.
Otherwise, "good" code is code that is easy to understand, easy to modify without breaking things, easy to test. Some of that you can learn by building larger, more complicated projects and rethinking your approach if/when it gets big enough that you have trouble keeping up a mental model of your own code until you figure out how to make it more comprehensible. This comes pretty quickly on the job when you're making changes to massive pre-existing projects.
There's actually a code review StackExchange. :) https://codereview.stackexchange.com/
Or if it's too big for that, have a friend take a look; at the very least, you'll find out whether your project is written and organized in such a way that somebody else can pick it up and understand it without significant difficulty.
I'd throw in seeking constructive feedback from people better than you. Simply building the habit of getting feedback and the attitude to accept it graciously will set you up for success.
You could also get a bit of a leg up looking up open-source projects in the language of your choice and tracing through how certain pieces work. Builds some skill at comprehending larger systems written by somebody else, may teach you a few things about structure and organization.
FirefighterWeird8464@reddit
Shorter, more composable functions.