This document discusses the importance of writing clean code through proper formatting, use of standards, use of meaningful names, small single-purpose functions, proper commenting, and incremental improvements. It covers topics such as inconsistent formatting being a sign of buggy code, functions doing one thing well, eliminating unnecessary comments, and leaving code better than you found it. The overall message is that writing clean code requires work but results in more maintainable and understandable code.

1. I Don’t HateYou,
I Just Hate Your Code
— B R I A N R I C H A R D S —
@rzen // WPSessions.com // WebDevStudios.com

2. — C H A P T E R O N E —
Formatting is
important.
@rzen

3. — C H A P T E R O N E —
Formatting
indicator of buggy code
#1
Inconsistent spacing is the
@rzen

4. — C H A P T E R O N E —
Formatting
"When people look under the hood, we want them to be
impressed with the neatness, consistency, and attention to
detail that they perceive.We want them to perceive that
professionals have been at work. If they see a scrambled
mess that looks like it was written by drunken sailors, they
will conclude that the same inattention to detail pervades
every other aspect of the project."
— Robert Martin, Clean Code

5. — C H A P T E R O N E —
Formatting
If you do nothing else,
at least be consistent.
If you’re going to be consistent,
why not be consistently GOOD?
@rzen

6. — C H A P T E R T W O —
You’re a decent human being,
you should have standards.
@rzen

7. — C H A P T E R T W O —
Standards
http://make.wordpress.org/core/handbook/coding-standards/ @rzen

8. — C H A P T E R T W O —
Standards
http://wp.tutsplus.com/articles/cheat-sheets
/the-wordpress-coding-standards-an-introduction/
Tom McFarlin goes into great
detail about why these matter
and are good for the planet:
@rzen

9. — C H A P T E R T W O —
Standards
if ( $this_thing == true ) {
// some code
}
if ( true == $this_thing ) {
// some code
}
S T A N D A R D :
Y O D A :
@rzen

10. — C H A P T E R T H R E E —
Working Fast = Working Clean
@rzen

11. — C H A P T E R F O U R —
Meaningful Names:
Clarity is King
@rzen

12. function proj_breadcrumb() {
// some code
}
function proj_get_breadcrumb() {
// some code
}
— C H A P T E R F O U R —
Meaningful Names
Y O U R C O D E :
B E T T E R C O D E :
@rzen

13. — C H A P T E R F O U R —
Meaningful Names
function do_awesome( $p = 0, $u = 0 ) {
// some code
}
Y O U R C O D E :
function do_awesome( $post_id = 0, $user_id = 0 ) {
// some code
}
B E T T E R C O D E :
@rzen

14. — C H A P T E R F I V E —
Functions should do one thing,
they should do it well,
they should do it only.
@rzen

15. — C H A P T E R F I V E —
Functions
The first rule of functions
is that they should be small.
The second rule of functions
is that they should be
smaller than that.
@rzen

16. — C H A P T E R F I V E —
Functions
BAD Function:
346 Lines, does logic, HTML, JS & CSS
@rzen

17. — C H A P T E R F I V E —
Functions
/**
* Return a user's points.
*
* @since 1.0.0
*
* @param integer $user_id User ID.
* @return integer Total Points.
*/
function badgeos_get_user_points( $user_id = 0 ) {
if ( ! $user_id ) {
$user_id = get_current_user_id();
}
return absint( get_user_meta( $user_id, '_badgeos_points', true ) );
}
GOOD Function:
4 lines long, does one thing
@rzen

18. Your functions should accept
as few parameters as possible.
Zero is best, followed by one,
followed by two, followed by
a serious re-evaluation.
— C H A P T E R F I V E —
Functions
@rzen

19. — C H A P T E R S I X —
Don’t comment bad code,
rewrite it.
@rzen

20. — C H A P T E R S I X —
Commenting
— P R E F A C E —
You should document
EVERYTHING.
@rzen

21. — C H A P T E R S I X —
Commenting
1.Obvious behavior
2.Misinformation
3.Information better
stored elsewhere
4.Unused functionality
T H E N , E L I M I N A T E T H E S E C O M M E N T S :
@rzen

22. — C H A P T E R S I X —
Commenting
function badgeos_get_user_points( $user_id = 0 ) {
// Get the current user ID if none specified
if ( ! $user_id ) {
$user_id = get_current_user_id();
}
// Return points cast as a positive integer (or 0, if invalid data)
return absint( get_user_meta( $user_id, '_badgeos_points', true ) );
}
1.Obvious behavior
@rzen

23. — C H A P T E R S I X —
Commenting
function badgeos_get_user_points( $user_id = 0 ) {
// Get the site ID first
// Then get the current user ID, if none specified
if ( ! $user_id ) {
$user_id = get_current_user_id();
}
// If user has negative points, set value to zero
return absint( get_user_meta( $user_id, '_badgeos_points', true ) );
}
2.Misinformation
@rzen

24. — C H A P T E R S I X —
Commenting
function badgeos_get_user_points( $user_id = 0 ) {
// Updated May 10, 2014
if ( ! $user_id ) {
$user_id = get_current_user_id();
}
// Modified by BR
return absint( get_user_meta( $user_id, '_badgeos_points', true ) );
}
3.Information better stored elsewhere
@rzen

25. — C H A P T E R S I X —
Commenting
function badgeos_get_user_points( $user_id = 0 ) {
// Get current user ID
// Removed May 10, 2014
// if ( ! $user_id ) {
// $user_id = get_current_user_id();
// }
return absint( get_user_meta( $user_id, '_badgeos_points', true ) );
}
4.Unused Functionality
@rzen

26. — C H A P T E R S E V E N —
Leave code better
than you found it.
@rzen

27. — C H A P T E R S E V E N —
Be a Good Code Scout
Incremental
improvement
is better than
NO improvement.
@rzen

28. — C H A P T E R S E V E N —
Be a Good Code Scout
1.Apply standard formatting
2.Rename for clarity
3.Break apart a big function
4.Add a DocBlock
5.Eliminate bad comments
E V E N J U S T O N E F I X I S G R E A T :
@rzen

29. — C H A P T E R E I G H T —
Clean code
is HardWork™
@rzen

30. — B R I A N R I C H A R D S —
@ R Z E N
W P S E S S I O N S . C O M
W E B D E V S T U D I O S . C O M
fin.