Your one stop book summary, audiobook and book review spot for:
Clean Code Summary
About Clean Code Book
Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code "on the fly" into a book that will instill within you the values of a software craftsman and make you a better programmer--but only if you work at it.
What kind of work will you be doing? You'll be reading code--lots of code. And you will be challenged to think about what's right about that code, and what's wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.
Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code--of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and "smells" gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding
- How to tell the difference between good and bad code
- How to write good code and how to transform bad code into good code
- How to create good names, good functions, good objects, and good classes
- How to format code for maximum readability
- How to implement complete error handling without obscuring code logic
- How to unit test and practice test-driven development
See More
4.5/5 (0884 reviews)
Audio and text
Download free PDF
READABILITY IS KEY
The main objective when writing code is for it to be easily understood by humans. Remember, your fellow developers will interact with your code much more than machines will.
- Try to make your code more readable today. Use descriptive names and clear structures.
- Think about a piece of code that was hard for you to understand. What made it difficult, and how could it have been improved for readability?
70
NAME IT WELL
Choosing informative and meaningful names for variables, functions, classes, and other identifiers helps your code speak for itself, reducing the need for comments.
- Review your code today. Do the names of variables, functions, or classes reflect their roles and behaviors? Consider revising any ambiguous or unclear names.
- Reflect on a situation where a poorly named variable or function confused you. How could it have been named better?
65
ONE FUNCTION, ONE TASK
Each function you write should have a singular, well-defined responsibility. Keeping functions small and focused makes your code more maintainable and less prone to bugs.
- Check your code today for any functions that may be trying to do too much. Consider breaking them down into smaller, more focused functions.
- Can you recall a function you encountered that was trying to do too much? How might you redesign it for better clarity and simplicity?
63
Learning to write clean and descriptive comments inside your code requires skill, but you should avoid it! Learn how important (or not) are comments within your code through the first part of the clean code book
Write Better Comments Part 1.
Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.
Comments are not like Schindler's List. They are not "pure good." Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much, perhaps not at all.
1
Good Comments
Some comments are necessary or beneficial. We'll look at a few that I consider worthy of the bits they consume. Keep in mind, however, that the only truly good comment is the comment you found a way not to write.
1
Legal Comments
Sometimes our corporate coding standards force us to write certain comments for legal reasons. For example, copyright and authorship statements are necessary and reasonable things to put into a comment at the start of each source file.
Here, for example, is the standard comment header that we put at the beginning of every source file in FitNesse. I am happy to say that our IDE hides this comment from acting as clutter by automatically collapsing it.
/ Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
1
If you are looking for a better version of yourself , i have a quote to start with
"Later equals never" le blanc's Law
i have readt this quote in "clean code" , so since I'm a IT student I been looking for great books to improve my codes .. and there where my eyes stopped on this amazing quotes , i'd love to share it with you . Let it be the quote of 2023 β€οΈπ«
4
Reduced duplication, high expressiveness and early building of simple abstractions. That's what makes clean code for me.
RON JEFFRIES
4
Ch2. Meaningful Names
- ο»ΏUse intention revealing names (elapsedTimeInDays vs d)
- Class names should contain nouns and not verbs. Avoid Manager, Processor, Data, Info in class names.
- Method names should have verbs. Accessory, mutators and predicates should be named for their values and prefixed with get, set, is
- Use searchable names
- Make meaningful distinctions
4
Software Developers will never be abstracted away!
As software requirements are complex, numerous and hard to explain, we can only abstract to the point of requirements. We cannot abstract away the specifications and requirements so There will always be someone who translates these requirements for machines.
Call then developers or something else. They will be there.
1
Supercharge your mind with one idea per day
Enter your email and spend 1 minute every day to learn something new.
I agree to receive email updates