Nothing~Whitespace

This talk is about clean code from a different view

Tabs vs Spaces

• Use the same everywhere
• Doesn't matter which you choose
• Only slide on tabs vs spaces!

Purpose of talk

• Show similarites
  • Business Documents vs Source Code
  • User Experience vs Source Code

Why

• We read code much more often then we write
  • 90% vs 10%?
• Be more productive / cheaper maintenance
• Less WTF / day. Be kind to your colleagues and have fun at work

https://www.simplypsychology.org/maslow.jpg

Maslow's hierarchy of needs

Physiological needs

• Code hygiene (Syntax, formatting, basic rules)

Safety needs

• Understand code

• Deliver business value

Belonginess and love needs

• Collective ownership

• Collaboration and continuous improvement

• Learn from each other

Esteem needs

• Be proud of your work

• Affect technology choise

Self-Actualization

• Create a new cool product
• Total Freedom

Business documents

VS

Source Code

• Source code is worth a lot of money, why not reflect that by writing proper code?
• Economists and jurists are more strict than software developers when writing documents. We should learn from them.

Capital letter starts a sentence

vs

Classes are substantives that starts with a capital letter

One and only one space between sentences

vs

Use one(1) strategy for spacing

val i = 0 / val i=0

No misspelled words

vs

No misspelled variable/function/class names

Invalid parts of texts are removed (strike through)

vs

Remove unused variables and other dead code

No grammatical errors

vs

No warnings

Result of bad business documents

• Author considered careless
• A consultant with bad written language in the CV will not produce good code quality

Result of bad code hygiene

• Slower to read - how much?
• Harder to read
• Some colleagues become annoyed
• Broken window

Tools/methods to improve code hygiene

Static code analyses

• Lint, PMD
• SonarCobe
• Use as build step
• Discuss rules to spread philosophy

Use a proper IDE

• Built in support for rules
  • Clear warnings
  • Checkin actions
• It is not cool to use vi/emacs

User Experience

VS

Source Code

• Pedagogic
• Efficient
• Pleasant

Characteristics of good UX

Code is not a puzzle

return entityServiceRegistry.getEntityService(type)
        .flatMap(entityService -> entityService.getEntity(Long.parseLong(id))
            .flatMap(entity -> entityServiceRegistry.getEntityService(sourceType)
                .flatMap(sourceEntityService -> {
                      ......
                }

Pedagogic text/code

• Use clear and vocabulary
• Reformulate sentences until text is pedagogic correct
• Exactly the same as with code

• Structure the text/code.
  • One chapter is about one thing
  • Group together code with the same functionality
• I prefer a structure with domain focus instead of technical focus
• Levels of structures
  • Projects -> Folders -> Files

Structure

Example of no structure

Groups of code blocks inside a file

• Classes/functions -> methods -> lines of code

• Inside a file, the tool is blank lines (0, 1, 2) to visually separate blocks

• 2 > 1 > 0

• Never blank lines inside a function. Text without blank rows is only hard to read if it is too long

• Python/C#/Scala/JavaScript support more classes / functions in a file - consider 2 blank lines.

All source code is whitespace significant!

https://www.python.org/dev/peps/pep-0008/#blank-lines

Keep abstraction level

• Red thread
• Hide details (appendix, footnotes, separate pages, functions, libraries).
• Compare
  • User manual or advertisements
  • Meetings where you go into too much details
• It should be possible to find details. Avoid generic functional programming magic code before entering details

Headlines

• Highlighting on web page
• Fewer words -> Bigger font
• Slogans (Don't be evil)
• Class names

Details

• Method names/implementation
• Footnote/appendix

Result of bad user experience

• Less efficient users
• Loss of customers

Result of code that is not easily understandable

• Slower to read - how much?
• Harder to read
• Some colleagues become annoyed

Tools/methods to make code more understandable

Tech meetings

• Shared code philosophy / Collective ownership

• Exercise: What is important in code for each team member?

• Expectations on each other
• Group dynamics change when members join/leave the group
• Increased knowledge of architecture
• Create motivation and responsibility

Pair/mob programming / Code reviews

• Continuation/implementation of tech meeting results
• Great exercise in understanding code written by others
• Teaching is the best way of learning
• Part of 'Definition of Done'

Shared code

• Single developers are generally more lazy, although some takes even more responsibility
• Rotate developers in the system

Refactoring / Scout rule

Don't even ask for time to do it!

Documentation / Intro

• Broad knowledge about domain / architecture is important for developer to be pedagogic in the code

Static code analyses

Cyclomatic complexity

Tests / TDD(?)

Too much mocking is a sign of code smell