Robert Cecil Martin

Professional work In 1991, Martin founded Object Mentor, now defunct, which provided instructor-led training on the extreme programming methodology. , he operated Uncle Bob Consulting, which provides consulting and training services. He serves as Master Craftsman / Mentor at Clean Coders, a company run by his son Micah Martin, and produces training videos.

In a 2024 interview Martin stated that he is programming primarily with Clojure.

Software principles advocacy

Martin is a proponent of software craftsmanship, agile software development, and test-driven development.

He is credited with introducing the collection of object-oriented programming (OOP) design principles that came to be known as SOLID.

Publications 1995. Designing Object-Oriented C++ Applications Using the Booch Method. Prentice Hall. . 2000. More C++ Gems. Cambridge University Press. . 2001. Extreme Programming in Practice. Addison-Wesley. . 2002. Agile Software Development, Principles, Patterns, and Practices. Pearson. . 2003. UML for Java Programmers. Prentice Hall. . 2006. Agile Principles, Patterns, And Practices in C#. Pearson. . 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. . 2011. The Clean Coder: A Code Of Conduct For Professional Programmers. Prentice Hall. . 2017. Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. . 2019. Clean Agile: Back to Basics. Prentice Hall. . 2021. Clean Craftsmanship: Disciplines, Standards, and Ethics. Addison-Wesley Professional. 2023. Functional Design: Principles, Patterns, and Practices. Addison-Wesley 2024. We, Programmers: A Chronicle of Coders from Ada to AI. Addison-Wesley Professional.

Guests Notable guests of his video channel include Grady Booch and Ward Cunningham.

Clean Code

One term that is connected with Robert Martin is "Clean Code". It is the name of a book that he wrote, a firm that he owns, a class that he teaches,

Short functions A core teaching from Clean Code reads "Functions should do one thing. They should do it well. They should only do it." Martin tells how impressed he was by a program by Kent Beck: "Every function [..] was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That's how short your functions should be."

John Ousterhout disagrees with this advice: "once a function gets down to a few dozen lines, further reductions in size are unlikely to have much impact on readability. [..] More functions means more interfaces to document and learn. If functions are made too small, they lose their independence [..]" For Ousterhout, functions and other modules should be "deep", but have a small interface. Ousterhout also disagreed with Martin's advice against code comments, and for test-driven development. Martin and Ousterhout discussed these points of disagreement and clarified their views in a long dialogue.