writing clean and maintainable code
TRANSCRIPT
WRITING CLEAN AND MAINTAINABLE CODE
WordCamp Norway 2015
Marko Heijnen
• Lead developer of GlotPress
• Core contributor for WordPress
• Working for 1&1 as their WordPress specialist
• Fan of new technologies
Quick note This talk is not only for developers.
Knowing how code should look like is important to judge it’s quality.
Bad code can bring your company down
Clean code
Some parts of this presentation are from the book “Clean Code” from Robert C. Martin aka Uncle Bob
So what is clean code?
– Bjarne Stroustrup, inventor of C++
“I like my code be elegant and efficient”
“Clean code does one thing well”
Elegance
– Grady Booch, author of Object Oriented Analysisand Design With Applications
“Clean code is simple and direct”
“Clean code reads like well-written prose”
Simple, direct, readable
– Dave Thomas, founder of OTI
“Clean code can be read”
“Clean code should be literate”
Literate
– Michael Feathers, author of Working Effectively with Legacy Code
“Clean code always looks like it was written by someone who cares”
Care
– Ron Jeffries, author of Extreme Programming Installed
“No duplication, one thing, expressiveness, tiny abstractions.”
Small, expressive, simple
– Ward Cunningham, inventor of Wiki, Fit, coinventor of eXtreme Programming. Motive force behind Design Patterns
“You know you are working on clean code when each routing you reads turns out to be
pretty much what you expected.”
What you expected
Variables, functions and methods
Meaningful names
• Intention-Revealing Names
• English Readability -> is_user_logged_in()
• Avoid disinformation
• Use pronounceable names
Meaningful names
• Classes should have a noun or noun phrase names but should not be a verb
• Method names should have verb or verb phrase names
• Use descriptive names
The code
• Should be very small!< 150 characters per line and < 20 lines
• Do one thing and do that right
• Limit it to one level of abstraction
• Reading code from top to bottom
• The ideal number of arguments for a function is zero
The code
• Don’t use flag arguments • passing a boolean into a function
• Pass objects as a function argument to reduce the arguments
• Have no side effect, does what is expected
• Don’t repeat yourself
• Only return data once
What does it not mean
Having set requirements like PHP 5.4 >It happens when the functionality is required
Using namespaces Important for projects with a lot of dependencies
The use of autoloaders It could enhances startup time but it’s not the place
to do so
Most of WordPress code base but every release it does get better
What does this mean for WordPress?
What does this mean for WordPress?
• Follow the WordPress coding standards
• A shared code base is an important aspect for clean code
• Have it prefix with something that is unique
What are the violations in WordPress
• A lot of global variables
• Functions/Methods should never echo
• Returning WP_Error instead of exceptions
• WP_DB
Last but not least Test Driven Development: Unit Tests
The three laws of Test Driven Development
• First law You may not write production code until you have written a failing unit test
• Second lawYou may not write more of a unit test than is sufficient to fail, and not compiling is failing
• Third lawYou may not write more production code than is sufficient to pass the currently failing test
Unit tests is the best documentation of your codeIt shows how you intended your code to be used
Keep test clean with the same standards as your production code.
Readability is keyMaybe even more important then
your production code
A single unit test should contain
• Single concept per test
• One assert per test is a good guideline
• Five other rules: F.I.R.S.T • Fast • Independent • Repeatable • Self-Validating • Timely
Clean code & me
Clean code & me
• I never studied Computer Science
• I do care about quality and structure
• I refuse to do quick wins or hacks
• Work together with others to become better
• Applying unit tests on existing projects
• A lot of refactoring and WTF moments
WP_Image_Editor
What I have learned from working together with a Java developer
What I have learned from working together with a Java developer
• Start applying all the things I discussed
• Using OOP more then just wrapping functions in a class
• Using a Wrapper / Decorator pattern
• Think more in advance how things should work
• And also think what could change
An hour discussion about hooks in WordPress
