14 hours (usually 2 days including breaks)
There are no specific requirements needed to attend this course.
Why do we need Clean Code? Programs evolve, therefore the code is continuously updated it can be very, very difficult to go back through unclean code to find and update the source code on average, the cost of writing the original code is only 40% of the total cost of a system; 60% of the cost, on average, is spent maintaining and updating code. Bad code dramatically increases that 40/60 ratio, bordering on 20/80 in the worst cases; the more unclean the code is, the more time we just spend updating it.
Good and standardized naming
-names of packages, files, classes, voids and functions as well as variables need to have meaningful names derived from their purpose
-should be readable
-should be searchable
-consider the namespace we're generating; does it make sense?
Classes, objects and data structures
-there's a difference between objects that do something and structures that simply contain data
-when to use data structures, and why
-when to use objects, and why
-OOD and abastraction
-getters/setters and why
-better to have many small classes, with many small voids and functions
-there are good and bad comments;
-we need to know how to generate good comments and forget about the rest
-one thing only
-arguments (good and bad)
-unintended side effects
-when to handle errors, when to let them bubble up
-if we handle an exception, what do we do with it and why
-custom error handling classes
Code Formatting: how can we better format the code
Test-Driven Design: Open discussion of Uncle Bob's idea that programs should be TDD
I really liked that there were a lot of practical exercises in which you could put the learned immediately into action.
The atmosphere was very nice, much more relaxed conversation than classic teaching style. Also, several of the techniques, especially those I doubt would hold up or be worth it (effort-gain-wise) under “real world” work conditions (as mentioned above) made me reflect on my coding style, and why I do or don't do some things (both on topics presented int he course and related ones), which I don't do that often (needed the impetus) but is really useful, even if I come to the conclusion that my style already suits my needs well.
Greentube Internet Entertainment Solutions GmbH