Book about good coding practices?
Posted by Lucid121@reddit | learnprogramming | View on Reddit | 17 comments
Does anyone know a book that gives guide how to make code efficient, simple for the human eye(readable) and using less space for same task. It can be for any language c++, Java, python, etc. I just want to know good coding practices.
Last_Being9834@reddit
The goal of a developer is to have main() as small as possible.
Then I would say Clean Architecture, SOLID and not trying to optimize early are the most common coding practices.
Once you finally have something working don't try to overfit it as you might decrease flexibility in case you want to expand your code later.
CodeTinkerer@reddit
It can be hard to put these into practice. You end up picking a few things and trying those out first, then slowly add other ideas.
Your priority should be readability first, then maybe make it efficient. Why? Some beginners (more true 30-40 years ago) believe the most efficient code is the best code. Maybe when computers were slow, this was important, but today, it's far less important.
Also, unless it's an algorithmic improvement, most programmers don't know what is causing their code to be inefficient. They make a guess, and hope that it works, but often, they can't tell a difference. The code runs fast to begin with and whatever fraction faster it runs is not even noticeable.
So, readability first. You may think coding is for computers, but it's also for humans. When you opt to make things run fast or use less memory, then you write code that's harder to read. Others will find your code confusing.
My advice is to learn how to write good function and variable names. This is not at all easy. But good names act as documentation. Many developers are lazy when it comes to documentation. They find it a waste of time. At the very least, getting good function/variable names does improve readability.
You can see beginners opting to pick variable names like
x, y, zbecause they struggle to come up with good names.There's this idea that functions are meant to reuse code. That's true, but it can also be used as a kind of documentation.
For example, I encountered something similar to the following:
Let's say these codes indicate someone is tax-exempt internally in the database. They serve as a classification of the person's status, and numbers are used to be precise.
It would read better as
Even if you only call that function once, it makes it clearer. I was originally going to call this
isTaxExempt, but I renamed it tohasTaxExemptStatusbecause that felt more accurate to me.The other common tip is: DRY. Don't Repeat Yourself.
If you see yourself copying-pasting the same code over and over, then make it into a function and refactor all of that code.
There are other more sophisticated tips, but I'd say start with those two.
khooke@reddit
Even better, define constants for 10, 12 and 30 with descriptive names that explain to the reader what those values are. As a reader I’ve no idea what those values represent. Those types of values usually represent something that is meaningful to the business, so use those names. E.g.
private static final int SINGLE_TAX_FILER_TAX_BAND1 = 10;
khooke@reddit
Even better #2 - depending on your language these should be defined using an enum or similar.
CodeTinkerer@reddit
Yeah, Java even permits these enums to have methods on them, if memory serves.
CodeTinkerer@reddit
Oh yes, they call these magic constants. Also, a useful and simple idea.
brikis98@reddit
Code Complete by Steve McConnell. Strengths: provides a strong, comprehensive foundation for how to think about programming and software engineering that I recommend to all developers. Weaknesses: the book is on the long side; the book is a bit dated, so no mention of open source, cloud, CI/CD, TDD, etc; focuses mostly on OO languages (C++, Java), with no mention of functional programming.
Clean Code by Robert C. Martin. Strengths: an excellent guide to writing code that is readable, maintainable, changeable, and testable; includes tons of examples, so instead of getting just a list of "rules" to follow, you get to see how to iteratively improve code, step by step. Weaknesses: has taken a lot of flak recently for some of the recommendations (e.g., very short functions), or perhaps due to hate for the author (who admittedly can be off putting), but I still think it's well-worth reading for all programmers; focuses mostly on OO languages (C++, Java), with little mention of functional programming.
A Philosophy of Software Design by John Ousterhout. Strengths: does a good job of defining complexity in software and the key causes of it; good discussions of information hiding, error handling, and conventions; contains some interesting counter-arguments to the practices in Clean Code, so it's good to read the books side-by-side. Weaknesses: focuses mostly on OO languages (C++, Java), with little mention of functional programming; the discussions of strategy vs tactics and trends felt a bit weak.
Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. Strengths: the best book I've seen on teaching you how to write automated tests; makes a compelling argument for how tests lead to better software design; includes many examples, and shows you how to use tests to iteratively produce better code. Weaknesses: the book focuses entirely on Java and OO, so yet again, functional programming is ignored; the book can get boring at times when it gets deep into the weeds of the Java Swing threading model.
Seven Languages in Seven Weeks by Bruce A. Tate. Strengths: a fantastic way to get exposure to not only multiple different programming languages (Ruby, Haskell, Prolog, Io, Erlang, Clojure, Scala), but also multiple different programming paradigms (OO, functional programming, logic programming, meta programming, concurrency constructs, type systems), which is a terrific way to become a better programmer; lots of great exercises in the book that give you a taste of what makes each language and paradigm unique. Weaknesses: it's hard to be an expert in so many different languages, so some of the chapters are stronger than others.
justUseAnSvm@reddit
I can't stand clean code. It doesn't make sense.
Still good to read, but you gotta keep an open mind about this stuff.
Lucid121@reddit (OP)
Thanks man
PassengerOk493@reddit
The only problem with such books - they got outdated very quickly. And the one that was giving good advices back when it got published will be a complete trash (most likely) after 1-2 years. Maybe I'm wrong
retroroar86@reddit
LOL. Many are somewhat timeless or at least give insights that takes a long time to experience yourself. There are books from the 90s like «The Art of Unix Programming» that is still viable, and early 2000s also.
PassengerOk493@reddit
Means that I’m wrong 🤷♂️
retroroar86@reddit
There’s quite a few gems of the old books, if you can buy any second hand you can probably find a bargain.
If they are still published and printed new today it attests to their timeless value.
PassengerOk493@reddit
Make sense. Good to know. Thanks
Jason13Official@reddit
In the year of our lord 2025, programmers don’t need to worry so much about the file size of their source code. Make it work, then optimize it. (Optionally, then make it pretty)
Triumphxd@reddit
I think you are looking more for a style guide, code looks cleaner when consistent styling is followed. Writing efficient and readable code is a learned process that to be honest you can only really gain from code reviews and reading good code. Just my opinion.
I will say, try and make your code self documenting. Instead of using single letter variables make them meaningful, so much so that you don’t need to leave any comments to understand the code when you first read it.
desrtfx@reddit
Even though it has fallen out of favor:
Quite a bit of the information in that book is still very good