Slide 1

Slide 1 text

Best practices for good(ish) and clean(ish) code PyConZa 2022

Slide 2

Slide 2 text

Who am I

Slide 3

Slide 3 text

Why this talk

Slide 4

Slide 4 text

Why this talk

Slide 5

Slide 5 text

What’s Clean Code •Readable •Maintainable •Elegant •Testable

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Can be inherited and enhanced by other developers other than the original author Ask yourself if the code is “clean” enough

Slide 9

Slide 9 text

Clean Code Measurement

Slide 10

Slide 10 text

Owning a mess, is it worth?

Slide 11

Slide 11 text

What prevents clean code? I’ll do the refactor later Rule of the thumb Spoiler alert: “Later” never comes

Slide 12

Slide 12 text

Owning a mess, is it worth?

Slide 13

Slide 13 text

Owning a mess, is it worth?

Slide 14

Slide 14 text

Owning a mess, is it worth?

Slide 15

Slide 15 text

Descriptive names The name should always represent the developer’s idea

Slide 16

Slide 16 text

Meaningful names

Slide 17

Slide 17 text

Searchable names

Slide 18

Slide 18 text

Class names Classes should have noun or noun phrase names like Customer, WikiPage, Account, AddressParser. Avoid words like Manager, Processor, Data … in the name of a class. A class name should not be a verb.

Slide 19

Slide 19 text

Method names Methods should have verb of verb phrase names like post_payment, delete_page, save. Method names should say what they do!

Slide 20

Slide 20 text

Comments sometimes lie

Slide 21

Slide 21 text

Code never lies

Slide 22

Slide 22 text

Code never lies

Slide 23

Slide 23 text

If they don’t lie, they can be lazy Crime: using a comment to avoid programming effort.

Slide 24

Slide 24 text

If they don’t lie, they can be lazy Crime: using a comment to avoid programming effort.

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Only one thing

Slide 27

Slide 27 text

Only one thing

Slide 28

Slide 28 text

Extract, extract, extract

Slide 29

Slide 29 text

Extract, extract, extract

Slide 30

Slide 30 text

Small cognitive/cyclomatic complexity 🙁

Slide 31

Slide 31 text

Small cognitive/cyclomatic complexity 😊

Slide 32

Slide 32 text

Advantages of measuring software complexity 1. Better Test Coverage

Slide 33

Slide 33 text

Advantages of measuring software complexity 3. Reduced Risk

Slide 34

Slide 34 text

Advantages of measuring software complexity 3. Lower Costs

Slide 35

Slide 35 text

Law of Demeter (“only 1 dot”) Lieberherr, K.J.; Holland, I.M. (September 1989). "Assuring good style for object-oriented programs". IEEE Software. 6 (5): 38–48. doi:10.1109/52.35588. Ask a dog to walk 🙅 book.pages().last().text()

Slide 36

Slide 36 text

Law of Demeter: drawbacks it won't apply to cats

Slide 37

Slide 37 text

“Premature optimisation is the root of all evil” — Donald Knuth

Slide 38

Slide 38 text

Continuous Refactoring “The most common “presenting” pathology in the hoarded codebases I’ve seen — by far — is that developers don’t feel they have time and/or permission to refactor code.” — Sarah Mei [Refactoring is] a very core technique to the whole agile way of thinking because it fi ts in with the whole way in which we can build software in a way that it can change easily … Refactoring is central to this because refactoring is a disciplined way of making changes. ” — Martin Fowler

Slide 39

Slide 39 text

Tests matter “How can I make sure that if I change this, nothing else breaks?”

Slide 40

Slide 40 text

… also experience matter Most popular code smells Duplication Improper use of inheritance Unnecessary complexity Convoluted Code Useless/misleading comments Tight coupling No Code Reviews Over abstraction Huge methods Design Pattern overuse Poor naming No test Commented code / code that’s not used Improper usage of private and public objects

Slide 41

Slide 41 text

Thanks❤ github.com/ernestoarbitrio twitter.com/__pamaron__ Questions? 🤔