Building maintainable Software-java Write clean Code
Writing Clean code is the what you must does in order to call yourself a professional.
-robert C. Martin
guideline:?
Write Clean Code.
? Do the
leaving code smells behind after developmentwork.
? This improves maintainability because clean
code is maintainable code.
Code smells is coding patterns, that hint, a problem is present. Introducing or not removing such patterns are bad practice, as they decrease the maintainability of code.
Leave No Trace
Boy Scouts has a rule that says, "leave the campground cleaner than you found it." Applying the boy Scout rule to software development means that once is writing or modifying a piece of code, you have The opportunity to make small improvements as well. The result is this you leave the code cleaner and more maintainable than you found it. If you were adjusting a piece of code now, apparently there was a need for maintaining it. That increases the chance so you'll revisit that same code later.
When you revisit this code again, you'll benefit from the refactoring is doing now.
How to Apply the guideline
Trying to was a clean coder was an ambitious goal, and there was many best practices so you can follow. From our consultancy experience we have distilled seven developer ' boy Scout rules ' that'll help you to prevent code SME LLS that impact maintainability the 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 is discussed here specifically because in our practice we see many flaws in Implementing Exception Handling:
?
Always catch exceptions. You is logging failures of the system to help you understand these failures and then improve the system's reaction to the M. That means the exceptions must always be caught. Also, in some cases a empty catch block compiles, but it's bad practice since it does isn't provide information about the Context of the exception.
?
Catch speci€c Exceptions. Exceptions traceable to a specific event, you should catch specific exceptions. General exceptions This does not provide information specific to the State or event, triggered it fail to provide that T Raceability. 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 being "bothered" with detailed exceptions, since they is mostly confusing and a security bad practi CE (i.e., providing more Information than necessary about the inner workings of the system).
Reading notes:
Building maintainable Software:ten guidelines for Future-proof Code
by Joost Visser
Copyright? Software improvement Group, B.V. All rights reserved.
Printed in the states of America.
Published by O ' Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O ' Reilly Books is purchased for educational, business, or sales promotional use. Online Editions is
Also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/
Institutional sales department:800-998-9938 or [email protected]
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
Building maintainable Software-java Write clean Code
