Robert C. Martin | |
|---|---|
| Martin in 2020 | |
| Born | Robert Cecil Martin 5 December 1952 [1] |
| Other names | "Uncle Bob" Martin |
| Occupations | Software engineer, [2] instructor |
| Known for | Agile Manifesto, SOLID principles |
| Children | 4 |
| Website | cleancoder |
Robert Cecil Martin (born 5 December 1952), colloquially called "Uncle Bob", [3] is an American software engineer, [2] instructor, and author. He is most recognized for promoting many software design principles and for being an author and signatory of the influential Agile Manifesto. [4]
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. [5] [6]
Martin joined the software industry at age 17 and is self-taught. [7]
In 1991, Martin founded Object Mentor, [8] now defunct, which provided instructor-led training on the extreme programming methodology. [9] As of November 2023 [update] , he operated Uncle Bob Consulting, which provides consulting and training services. [10] He serves as Master Craftsman / Mentor at Clean Coders, a company run by his son Micah Martin, and produces training videos. [11]
In a 2024 interview Martin stated that he is programming primarily with Clojure. [12]
Martin is a proponent of software craftsmanship, agile software development, and test-driven development. [13]
He is credited with introducing the collection of object-oriented programming (OOP) design principles that came to be known as SOLID. [14]
Notable guests of his video channel include Grady Booch and Ward Cunningham.
One term that is connected with Robert Martin is "Clean Code". It is the name of a book that he wrote, [15] a firm that he owns[ citation needed ], a class that he teaches, [15] and a software paradigm that he supports. The software paradigm involves SOLID, Test Driven Development, Structured Programming, Object Oriented Programming, and certain Design Patterns. [16]
A core teaching from Clean Code reads "Functions should do one thing. They should do it well. They should only do it." [17] 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." [18] 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 [..]" [19] For Ousterhout, functions and other modules should be "deep", but have a small interface.