Building Maintainable Software-java篇之 Write Clean Code

Building Maintainable Software-java篇之 Write Clean Code

Writing clean code is what you must do in order to call yourself a professional.
—Robert C. Martin

Guideline:

• Write clean code.
• Do this by not leaving code smells behind after development work.
• This improves maintainability because clean code is maintainable code.


Code smells are coding patterns that hint that a problem is present. Introducing or not removing such patterns is bad practice, as they decrease the maintainability of code. 

Leave No Trace

Boy Scouts have a rule that says, “leave the campground cleaner than you found it.” Applying the Boy Scout rule to software development means that once you are writing or modifying a piece of code, you have the opportunity to make small improvements as well. The result is that you leave the code cleaner and more maintainable than you found it. If you are adjusting a piece of code now, apparently there is a need for maintaining it. That increases the chance that you will revisit that same code later.
When you revisit that code again, you will benefit from the refactoring you are doing now.

 How to Apply the Guideline

 Trying to be a clean coder is an ambitious goal, and there are many best practices that you can follow. From our consultancy experience we have distilled seven developer “Boy Scout rules” that will help you to prevent code smells that impact maintainability most:

1. Leave no unit-level code smells behind.

2. Leave no bad comments behind.

3. Leave no code in comments behind.

4. Leave no dead code behind.

5. Leave no long identifier names behind.

6. Leave no magic constants behind.

7. Leave no badly handled exceptions behind.

Three guidelines for good exception handling are discussed here specifically because in our practice we see many flaws in implementing exception handling:
• Always catch exceptions. You are logging failures of the system to help you understand these failures and then improve the system’s reaction to them. That means that exceptions must always be caught. Also, in some cases an empty catch block compiles, but it is bad practice since it does not provide information about the context of the exception.
• Catch speci€c exceptions. To make exceptions traceable to a specific event, you should catch specific exceptions. General exceptions that do not provide information specific to the state or event that triggered it fail to provide that traceability. Therefore, you should not catch Throwable, Exception, or RuntimeException directly.
 
 • Translate speci€c exceptions to general messages before showing them to end

users.

End users should not be “bothered” with detailed exceptions, since they are mostly confusing and a security bad practice (i.e., providing more information than necessary about the inner workings of the system).

读书笔记：

Building Maintainable Software: Ten Guidelines for Future-Proof Code
by Joost Visser
Copyright © 2016 Software Improvement Group, B.V. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/
institutional sales department: 800-998-9938 or corporate@oreilly.com.
Acquisitions Editor: Rachel Roumeliotis
Editor: Nan Barber
Production Editor: Matthew Hacker
Copyeditor: Rachel Monaghan
Proofreader: Marta Justak
Indexer: WordCo Indexing Services, Inc.
Interior Designer: David Futato
Cover Designer: Randy Comer
Illustrator: Rebecca Demarest
February 2016: First Edition
Revision History for the First Edition
2016-01-25: First Release
See  http://shop.oreilly.com/product/0636920049159.do