O'Reilly logo
live online training icon Live Online training

Clean Code

Robert Martin

Robert C. “Uncle Bob” Martin is a software craftsman, and one of the leading names in contemporary software development. His books and videos are immensely popular. This new live training session is based on his most popular and best-selling book, Clean Code. If code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way! Uncle Bob will use his signature presentation style to provide attendees with the foundation needed to begin writing good code, and transforming bad code into good code.

What you'll learn-and how you can apply it

  • Keen insight into the motivation for clean code
  • Practical advice on the proper size and structure of functions
  • Several practical heuristics for naming classes, functions, and variables
  • Guidance on when and where to write comments, and when not to
  • Simple and actionable rules for code formatting

This training course is for you because...

  • You are an application developer, programmer, software engineer, or software architect who works with code.
  • You take pride in your organization’s development efforts, understand the basis of software development, and appreciates how the code base can impact the entire development organization.
  • You want to learn how to build clean code, and help others in your organization do so, too.

Prerequisites

  • There are no prerequisites for this Clean Code training session, but it would be optimal if participants have practical software development experience and familiarity with the terminology and practices around code construction and maintenance.

Resources:

About your instructor

  • Robert C. Martin (Uncle Bob) has been a programmer since 1970. He is the co-founder of cleancoders.com, which offers online video training for software developers, and is the founder of Uncle Bob Consulting LLC, which offers software consulting, training, and skill development services to major corporations worldwide. He served as the Master Craftsman at 8th Light, Inc., a Chicago-based software consulting firm. He has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He served three years as the editor-in-chief of the C++ Report and served as the first chairman of the Agile Alliance.

    Martin has authored and edited many books, including Clean Architecture, The Clean Coder, Clean Code, UML for Java Programmers, Agile Software Development, Extreme Programming in Practice, More C++ Gems, Pattern Languages of Program Design 3, and Designing Object Oriented C++ Applications Using the Booch Method.

Schedule

The timeframes are only estimates and may vary according to how the class is progressing

Introduction (10 min)

Section 1 Names (30 min)

  • Names are everywhere in software. We name our variables, our functions, our arguments, classes, and packages. We name our source files and the directories that contain them. We name our jar files and war files and ear files. We name and name and name. Because we do so much of it, we’d better do it well. What follows are some simple rules for creating good names.

Break (5-10 min)

Section 2: Functions (45 min)

  • In the early days of programming we composed our systems of routines and subroutines. Then, in the era of Fortran and PL/1 we composed our systems of programs, subprograms, and functions. Nowadays only the function survives from those early days. Functions are the first line of organization in any program. Writing them well is the topic of this chapter.

Section 3: Comments (30 min)

  • Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

Break (5-10 min)

Section 4: Formatting (30 min)

  • You should take care that your code is nicely formatted. You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply. It helps to have an automated tool that can apply those formatting rules for you.

Conclusion (20 min) - Q&A