Writing better code

16
The exact year that Da Vinci completed the Mona Lisa is unknown, but most agree that he started it in 1503/1504 and worked on it for several years . He spent years perfecting this painting. Began it in Italy and finished it while living in France. X-rays and other tests with lasers and infrared light have revealed three earlier versions beneath the surface . Write Re-factor Re-Write

Transcript of Writing better code

Page 1: Writing better code

The exact year that Da Vinci completed the Mona Lisa is unknown, but most agree that he started it in 1503/1504 and worked on it for several years.

He spent years perfecting this painting. Began it in Italy and finished it while living in France.

X-rays and other tests with lasers and infrared light have revealed three earlier versions beneath the surface.

Write

Re-factor

Re-Write

Page 2: Writing better code

WRITING BETTER CODEby JW

Page 3: Writing better code

"Make it correct, make it clear, make it concise, make it fast. In that order."

Wes Dyer

But Clear and Concise depends on the complexity…

Page 4: Writing better code

Complexity

- Can be removed Vs cannot be removed - Can be reduced Vs cannot be reduced - Inherent vs Induced

- Domain Vs Design

How do we hide complexity?

Page 5: Writing better code

Comments

- Explains What - Can become obsolete - Can confuse - Hides bad code

Page 6: Writing better code

COUPLING

Page 7: Writing better code

Coupling (dependency)

is defined as the degree of interdependence between two or more modules.

- build modules that are independent

Page 8: Writing better code

Reduce OOP Inheritance and favour OOP Composition

Page 9: Writing better code

COHESION

Page 10: Writing better code

Cohesionis defined as the degree to which all elements of a module work together as a functional unit.

- favour high cohesion and loose coupling

Page 11: Writing better code

WHERE TO START…long method…

Page 12: Writing better code

Why is long method bad

- Hard to read - Hard to understand - Hard to remember

- Hard to test - Hard to debug - Hard to code reuse

- Violates SRP - Cannot be optimised - lacks Cohesion - Many reasons to change

- Hides business rules - Obsolete comment

Lets see an example…

Page 13: Writing better code

Separation of Data

new QuoteViewExcelModel().countryFeeDetails(getCountryFeeDetails(quoteForm,quoteFeeOutputMap)).countryFeesTotal(getCountryFeesTotal(quoteForm,quoteFeeOutputMap)).x713FeeDetails(get713FeeDetails(quoteForm,quoteFeeOutputMap)).x713FeesTotal(get713FeesTotal(quoteForm,quoteFeeOutputMap)).translationFeeDetails(getTranslationFeeDetails(quoteForm,quoteFeeOutputMap)).translationFeesTotal(getTranslationFeesTotal(quoteForm,quoteFeeOutputMap)).terms(getCompanyName(request));

- Separation of data from view https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

- Builder pattern when many arguments https://en.wikipedia.org/wiki/Builder_pattern

- facilitate declarative style of programming

Page 14: Writing better code

Declarative style of programming

- Code should read like a story - Less like a puzzle - Should convey the intent - Can be functional - Comment on Why and not on What

Page 15: Writing better code

Declarative style of programming

Workbook quoteExcelWorkbook = Workbook.Create(workbook).createSheet("SheetName").begin("Quote generation")

.begin("Quote header").cell("A1").rowHeight(Workbook.ROW_HEIGHT_20).val(getCompanyName(request))

.range("A1:F1").merge()

.rBorder(Workbook.BORDER_TOP_BOTTOM, IndexedColors.ROYAL_BLUE, CellStyle.BORDER_THICK)

.cell("A2")

.rowHeight(Workbook.ROW_HEIGHT_20)

.val(getQuoteTitle(quoteForm))

.range("A2:F2").merge()

.cell("A3")

.val(getPatentDetails(quoteForm))

.range("A3:F3").merge()

.rBorder(Workbook.BORDER_TOP_BOTTOM, IndexedColors.ROYAL_BLUE, CellStyle.BORDER_THICK)

.end("Quote header")

Page 16: Writing better code

Future you should thank you

Focus on

- Maintenance- Understandability

- Embrace declarative style- Keep it short and simple- Single responsibility