Robert C. Martin
American software consultant
- 2 min read
- 4 chapters
Related on Lably
Through Object-oriented programming, SOLID and Structured programming
Martin has authored many books and magazine articles. He was the editor-in-chief of C++ Report magazine and served as the first chairman of the Agile Alliance.
Martin joined the software industry at age 17 and is self-taught.
Professional work
In 1991, Martin founded Object Mentor, now defunct, which provided instructor-led training on the extreme programming methodology. As of November 2023, 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.
Sign in to keep reading
3 more chapters are free with a Lably account.
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.
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, and a software paradigm that he supports. The software paradigm involves SOLID, Test Driven Development, Keep It Simple Stupid, Structured Programming, Object Oriented Programming, and certain Design Patterns.
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.