clean code: tips for writing clear and concise code

Clean Code: Tips for Writing Clear and Concise CodeBen Rand

Director of IT, Senior Developer

Job Industrial Services, Inc.

About the speaker

Ben Rand

Ben has been using AutoCAD since Release 12. He learned to program

using LISP in AutoCAD, worked his way up through VBA, VB6 and

VB.NET, and now spends most of his days programming in C#

(occasionally still in AutoCAD!), and dabbling in other languages such as

Java, Ruby and Python. He has worked in the Industrial Engineering

field for more than 17 years as a CAD Manager, developer and IT

Director. In 2013, he was the 2013 Top DAUG overall winner at AU, and

he served a mentor for the AutoCAD Mentor All-Star team.

Ben is the proud father of four children and enjoys reading and playing

a variety of sports including pickleball, volleyball, and tennis. In 2018,

Ben was a member of two USTA men's league teams. The 18 and over

team won the National Championship, while the 40 and over team was

the Finalist.

Course Objectives

Name classes, methods

and variables meaningfully

NMNAME MEANINGFULLY

CFCOHESIVE FOCUSED

UTUNIT TESTS

CCCLEAN CODE

Write more cohesive,

focused methods and

classes

Utilize unit tests to support

refactoring towards clean

code

Write cleaner code

Confession: I have written bad code

• Professionally

• In many languages:

• LISP

• VBA/VB6

• VB.NET

• C#

• Java

• Ruby

• Javascript

• I still write bad code, but I’m getting better at:

• Recognizing it when I do

• Doing something about it

http://beamiller.wikia.com/wiki/Confessions_of_a_Shopaholic

I'm not a great programmer; I'm just a good programmer with

great habits. ― Kent Beck

https://matrix.fandom.com/wiki/File:Matrix_Code.gif

Why is Bad Code…bad?

• Bad code works BUT

• Is hard to read

• Is hard to reason about

• Tries to do too much

• Uses confusing names

• Relies on magic numbers/strings

• Is hard to maintain

• Is poorly formatted

• Lacks unit tests

You have to work extra hard to work with bad code—over and over again.

Why is Clean Code better?

• Clean code works AND

• Is easy to read

• Is easy to reason about

• Is easy to extend

• Is easy to understand, including several

weeks or months from now

• Is easy to maintain

• Has unit testshttps://blog.linkedin.com/2012/08/01/inday-games

The computing scientist’s main challenge is not to get confused by the complexities of his own

making.― E. W. Dijkstra


Formatting• Indentation

• Samples 1-2

• Samples 3-4

• Magic numbers and strings

• Samples 5-10

• Spacing and line length

• Samples 12-13

Comments are, at best, a necessary evil.

― Robert C. Martin


Comments• Need to be maintained

• Samples 6, 15

• Explain sections of code (refactor and rename?)

• Samples 16-18

• Versioning information

• Slide 12

• Zombie code

• TODO and Regions

• Slide 13

//Modified by Ben

Prefer Version Control System (VCS) to comments

TODO comments often become clutter

Deleted code is debugged code.― Jeff Sickel


Functions• Short and do one thing

• Declare variables close to where used

• Avoid nested conditionals

• Slide 16

• Use verb-y names: Getxxx, Setxxx, Isxxx, Hasxxx

• Command or Query (not both)

• Samples 20-21

• Decomplicating Conditionals

• Slide 18-19

• Samples 23-24

• 25 declared variables

• Uncle Bob’s

recommendation for

method length?

• 20 lines

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough

to debug it.― Brian W. Kernighan


bool someCondition;

if(someCondition == true)

{

//do something

}

Conditionals

if(someCondition)

if(someCondition == false) if(!someCondition)

if(someCondition != false) if(!someCondition == false)

It’s sort of a double negative.― Donald J. Trump


Naming—Variables, Methods, Classes• Reveal intent

• Use long descriptive names instead of short cryptic names

• Use nouns for classes

• Use verb/verb phrases for methods

• Avoid single letter names

• Be pronounceable

• Sample 25

• Avoid “Hungarian notation” prefixes

• Sample 26

• Avoid disinformation

• Sample 28

One of my most productive days was throwing away 1000

lines of code.― Ken Thompson


Classes• Should be short

• Can I describe its purpose in 25 words or less, without using: if,

and, or, but?

• Use nouns for names

• SOLID: https://en.wikipedia.org/wiki/SOLID

• Single responsibility principle (SRP)—single reason to change

• Open/closed principle

• Liskov substitution principle

• Interface segregation principle

• Dependency inversion principle

https://en.wikipedia.org/wiki/SOLID

Unit Tests• Keep tests clean—readability!

• One assertion per test

• Single concept per test

• Organization: Arrange, Act, Assert

• F.I.R.S.T.:

• Fast

• Independent

• Repeatable

• Self-validating

• Thorough/Timely

Unit Tests – Test Driven Design (TDD)• Three Laws of TDD

1. You may not write production code until you have written a failing unit test.

2. You may not write more of a unit test than is sufficient to fail, and not

compiling is failing.

3. You may not write more production code than is sufficient to pass the

currently failing test.

--From Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin

See: https://blog.coryfoy.com/2006/08/tdd-bowling-game-part-1/ and

https://blog.coryfoy.com/2006/08/tdd-bowling-game-part-2/ for a tutorial on

TDD

https://blog.coryfoy.com/2006/08/tdd-bowling-game-part-1/

https://blog.coryfoy.com/2006/08/tdd-bowling-game-part-2/

Refactoring and Unit Tests: Credit Card Validator

Sample Code: Practice2_CreditCardProblem (Java)

SRP and Abstractions:CleanCodeLayer

Sample Code: CleanCodeLayer (C#)

Always code as if the guy who ends up maintaining your code

will be a violent psychopath who knows where you live.

--Martin Golding


Recommended Reading

• Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin

• Working Effectively with Legacy Code, Michael C. Feathers

• Dependency Injection in .NET, Mark Seeman

• Design Patterns: Elements of Reusable Object-Oriented Software, Erich

Gamma, et al.

• The Pragmatic Programmer: From Journeyman to Master, Andy Hunt

• Refactoring: Improving the Design of Existing Code, Martin Fowler

• Code Complete, Steve McConnell

• Head First Design Patterns, Eric Freeman

• The Art of Unit Testing: With Examples in .NET, Roy Osherove

Contact Me• Email: [email protected]

• Twitter: @leadensky

• LinkedIn: www.linkedin.com/in/leadensky

2018 Courses at AU• AS197578-L: Data Mining in AutoCAD with Data Extraction

• SD195561: Control Your Code: Introduction to Source Control for Programmers and

CAD Managers

• SD226637: Clean Code: Tips for Writing Clear and Concise Code

Pluralsight Course• https://www.pluralsight.com/courses/autocad-extracting-data-drawings

mailto:[email protected]

http://www.linkedin.com/in/leadensky

https://www.pluralsight.com/courses/autocad-extracting-data-drawings

https://www.pluralsight.com/

Autodesk and the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.

© 2018 Autodesk. All rights reserved.

Don’t forget to fill out your class survey

before you leave AU!

http://www.autodesk.com/creativecommons

clean code: tips for writing clear and concise code

Documents