Сколько return'ов должно быть в функции/методе?

Для меня второй вариант предпочтительней. Однозначно можно найти место где возвращается результат.

а мне по душе первый вариант, зачем лезть дальше в функцию, если (например) критичное условие не выполняется и остальное содержимое функции не будет применено к данному её вызову?

Пользуюсь первым вариантом.

Первый вариант. Когда я вижу return false; я понимаю, что в этой ситуации функция возвращает false. Когда я вижу $result = false; это значит, что переменной результата присваивается значение false. И я должен просмотреть весь оставшийся код, чтобы понять, вернется ли это значение из функции, перекроется ли ниже, или же даже, скажем, будет участвовать в серии логических операций ( $result = $result || $logicStatement ).
1. объект com.sun.java.swing.plaf.gtk.GTKLookAndFeel возвращается сразу же.

if ("gnome".equals(desktop)) {
          // May be set on Linux and Solaris boxs.
          return "com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
        }
        if ((osName.indexOf("Solaris") != -1) ||
           (osName.indexOf("SunOS") != -1)) {
          return "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
        }

2. Объект com.sun.java.swing.plaf.gtk.GTKLookAndFeel может быть перекрыт объектом com.sun.java.swing.plaf.motif.MotifLookAndFeel.

if ("gnome".equals(desktop)) {
          // May be set on Linux and Solaris boxs.
          result = "com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
        }
        if ((osName.indexOf("Solaris") != -1) ||
           (osName.indexOf("SunOS") != -1)) {
          result = "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
        }

Имхо, вопрос поставлен не совсем корректно: если возвращаемое значение сложновычисляемое и модифицируемо в ходе подпрограммы, то вариант будет со временной переменной. В простом случае, лично я лучше послушаю Фаулера и применю рефакториинг «встраивание временной переменной». Т.е. дело не в православности методики, а в требовании реалий. Религиозная же сторона дела рассматривалась тут.

Если думать о быстродействии, то первый вариант лучше (например когда systemLAF != null). Сразу ретурн и не надо выполнять дальнейших операций.

Использую retrun, когда нужно. Функция на 20 строк — какой смысл анализировать её (и человеку, читающему код, и интерпретатору), если на первой строке она не проходит проверку? Естественно, тут return и дело с концом. Это в общем. Однако, могут быть и частные случае, когда можно накапливать/модифицировать result и вернуть в конце.

Однако, бывают случае, когда ставят return'ы чересчур много «раздувая» код. Например:

if (a) {
  return a - 10;
} else {
  return false;
}

Предпочтительней в данном случае не писать else, т.к. return (если он будет) будет в if'е, это делает код более наглядным и снижает «раздутость»:

if (a) {
  return a - 10;
}
// остальные вычисления, на которые можно
// не смотреть, если был return выше
return false;

Очень интересный вопрос.

Я стараюсь писать достаточно маленькие функции, чтобы подобного вопроса не возникало вообще: 1-6 строчек вычисляем результат, последней строчкой возвращаем. Если функция получается длиннее, то что-то, скорее всего, не так.
Когда надо написать длинные if-ы (всякое бывает), обычно, что объявление result, что много return'ов особой погоды не делают.

Когда я использую вариант с result'ом, я обычно объявляю эту переменную как final, чтобы результат присвоить ровно один раз. Очень помогает когда возвращаешься к коду через несколько месяцев. И понятно, что хотел сделать, и испортить сложно.

Очень был удивлён Вашим кодом и кодом Вашего коллеги. Эти кусочки делают разные вещи. У одного из вас точно бага. Рассмотрите случай когда "swing.systemlaf" равно "CustomLAF", а "os.name" равно "Windows". Ваша функция вернёт "CustomLAF", а функция коллеги — "...WindowsLookAndFeel". Правьте код, пока не Вас не поймал QA.

Мне кажется надо судить не по коду, а по ситуации, остальное лишь дело вкуса.

Бывает момент когда возвращают в return функцию которая выводит какое-либо значение, а бывает и сплошные стринги :).
Если боремся за каждый байтик, то важно не повторятся. А если важна работа процессора, то быстрее будет присваивание…

Я конечно не супер-пупер профессионал, но что-то в этом духе…

Просьба не сильно пинать ногами. «Короли тоже бывали ефрейторами»…

я обычно выхожу как можно скорее.
не думаю, что могу обосновать почему. просто мне так больше нравится. не вижу ничего крамольного в другом подходе.

Парадигма с одной точкой выхода уже давно устарела.

Кстати, что ваш друг думает насчет выбрасывания исключений? Они ведь тоже создают еще одну точку выхода. Или он фанат Win32 и GetLastError?

Правильный вариант с временной переменной, он обычно всегда рекомендуется, да и код красивее получается. Но все зависит от алгоритма функции. Для некоторых случаев рекурсии иногда более педпочтителен второй вариант.

Одним словом, первый вариант лучше для объемных функций и предпочтительнее по теории, а второй вариант некоторые считают удобнее.

Лично я стараюсь использовать первый и честно говоря, уже привык к нему.

У вас код не эквивалентный, кажется: в первом случае вернется сразу systemLAF, во втором — даже если result = systemLAF, то property OS.name может его перебить. Во-первых, добавьте else к первому if. Во-вторых, писать надо так, чтобы было легко понять. Так что если это проверка предусловий, то лучше явно написать return сразу, а если это логика работы, то лучше иметь как можно меньше точек выхода.
Наилучший вариант — иметь такие короткие функции, чтобы много точек выхода разместить было негде.

Мне кажется, это дело вкуса.
Сам делаю один return, потому как привык, что должна быть одна точка входа и соотв. одна точка выхода.
Ну так мой мозг устроен )

Есть похожый вопрос на счет if'ов: как правильнее?
пример 1:

function test($param) {
    if(is_null($param)) {
        return false;
    }

    // ... code ...
    return $result;
}

пример 2:

function test($param) {
    if(!is_null($param)) {
        // ... code ...
        return $result;
    } else {
        return fasle;
    }
}

ну и учитывая вопрос топика, вырисовывается еще вариант:

function test($param) {
    $result = false;
    if(!is_null($param)) {
        // ... code ...
       $result = true;
    }

    return $result;
}

По моему первый вариант предпочтительнее, потому что я выхожу из функции сразу же по обнаружении что даной функции коректно не выполнится.

пост-детектор людей, учившихся программировать на Паскале

Как писали выше, МакКоннелл в «Code Complete» советует смотреть по ситуации: использовать множественные точки выхода из метода следует в том случае, когда это позволит улучшить читаемость. Если метод большой, это наоборот может усугубить ситуацию…

Я за первый вариант

Я обычно использую возврат в середине функции, если это возврат из-за выполнения/невыполнения какого-нибудь условия, то есть когда результат быстро вычисляется.

Если вычисление может пойти просто по двум разным путям, то стараюсь сохранять результат в переменной, а потом уже в самом конце его возвращать.

Я пишу на С++, так что смотрю на всё немного со своей колокольни, но, думаю, моё мнение актуально и для этого случая.
Когда нужно написать функцию с несколькими точками выхода, я смотрю, есть ли необходимость в различных завершающих действиях. Если есть, то пользуюсь вторым вариантом (дублировать завершающие операции считаю неверным).
Если же функция достаточно проста, и выход не сопровождается какими-либо дополнительными действиями, то делаю по первому — простому — варианту.
В конечном итоге надо смотреть на отсутствие дублирования кода и читаемость, это самый важный аргумент.

Почитайте на досуге: Кент Бек «Шаблоны реализации корпоративных приложений».

«одна точка входа и одна точка выхода» — имхо, самый православный вариант. Основной плюс его — улучшение структурированности кода в телах функций, при дебаге достаточно отслеживать изменения только одной «возвращаемой» переменной, нужен только один брекпойнт, чтобы увидеть состояния всех локальных переменных перед «возвратом результата». Минус — увеличивает вложенность скобок и сползание кода вправо. Для себя я давно уже как выбрал 2-й вариант, желаний пересмотеть это решение не возникало.