1. James Read <jread@redhat.com>
A Ramble on Clean Code
James Read

2. You may be a “coder” if... Use markup languages (HTML, LaTex)
Use compiled programming languages (C++, Java)
Use interpreted programming languages (shell scripting)
“Yeah, but clean code isn't important, I just hack every now and then...”

3. What is unclean code?
Unclean code is bad code. No need to patronize you, but it leads to unhappy developers and buggy software

4. How do I know if it is clean code?
Is it: reusable, portable, readable, efficient, functional, minimalistic, obvious, modular, independent, extensible and maintainable?
Unfortunately you wont appreciate clean code from its description, it has to be in your code base staring back at you.

5. Language designers aren’t doing nearly enough
Python – consistent indenting
Java – one (public) class per file
C# - a language with a purpose, but has some of the worst designed features ever
object extensions, event mechanism, single threaded UI, operator overloading, optional exception catching, undeclared exceptions, extend and override unmanaged objects, partial classes, comment regions, delegates (bad implementation of lambda functions)
Note: PHP probably wins the worst designed language award, but I love it.

6. Use comments very sparingly
Don't explain the obvious!
Don't ever comment out old code!
If you need to comment your code to explain a concept, is the code clean?
Comments to explain business decisions can be necessary.

7. Use libraries, don't reinvent the wheel
Coding something big or reinventing the wheel is great fun, but avoid it.
It's sometimes necessary (example later)
If you can, use libraries. You can swap between implementations.

8. Write small methods and classes
Methods (functions)
More than 10 lines is bad... really!
Think of the Single Responsibility Principle
Classes (objects)
Only make the bare essentials possible
Is this class a data structure or a data controller?

9. Premature optimization is EVIL
You don't get points for “highly efficient” but obscure code.
Is it maintainable?
If you are going to do something obscure, use a small comment that references a design doc

10. Use intention-revealing names
public void mkTS(int d)
Use strong verbs in method names (is..., set..., get...)
Avoid use of single character variable names
Avoid encodings (h not) int16_t intVehicleName
Use a convention (eg: camelCase)
public void makeTimesheet (int numberOfDays)

11. Use good design patterns
A pattern can tell you what the code is doing just by a class name. eg: JButtonClickObserver
Patterns already exist for almost everything you do in code.
Observer Pattern
Adaptor Pattern
Mediator Pattern
Visitor Pattern
...any many more!

12. Avoid bad design patterns
Non normalized database schemas (eg OBLT, EAV)
Singletons
Gold plating
“God” objects, which do way too much
Don't do use it just because it works!
Note: aka Anti-Patterns

13. Write automatically testable code
Code that is tested frequently and automatically leads to much faster development, less regression failures and more reliable software.
If you have not heard of unit testing, put the keyboard down and go read a modern software development book.

14. Use a one-click build system
Can you turn source code into distributable package with one click (or typed command)?
If you have to fiddle about building packages, human error will often get in the way

15. Egotistical example TCPDF (and its forks) RPDF
The most popular and maintained PDF library for PHP
Worst code I've ever seen, nightmares. Ridiculously bad.
28,768 lines of code, 1 file & class (that's a MB of source)
PDF generation time in 20+ seconds
RPDF
I learnt the PDF standard and coded it from scratch
It took about 10 days and is mostly feature complete with TCPDF
~2000 lines of code, 17 files & classes (only needs 3)
Equivalent PDF generation times in milliseconds

16. The only valid measurement of code quality is “WTF”s/minute

17. Highly Recommended Reading
Clean Code Robert C. Martin For every techie (teaches with Java)
The Pragmatic Programmer Andrew Hunt & David Thomas For frequent/career programmers

18. Fin
OpenOffice.org crashed 5 times during the production of this presentation, probably due to unclean code... and Oracle.