Какой стиль написания/оформления кода вам ближе?

[sse]

Стиль «отсутствие стиля» not detected :)

[spacetribe]

В этом вся фишка. Каждый хотя бы в подсознании склоняется к чему-то одному, и задача опроса — отсечь среднее и выяснить правду-матку.

[kurokikaze]

А третий вариант разве не подходит? )

[sse]

Нет :) Есть именно отсутствие стиля, т.е. «каша»: из операторов, символов, скачущие строки, разнобой выравнивания, лишние пробелы и т.п.

Мой предыдущий начальник смотрел даже на количество пустых строк между объявлением методов, чтобы оно было одинаково для всего файла и всех файлов. Мотивация следующая: «как можно доверить что-то серьезное человеку, который даже не может вставить одинаковое количество переводов строки?»

:)

[ISVir]

Куда приятнее:

<?php
echo 'Hello';
?>

Нежели:

[ISVir]

<?= 'Hello' ?>

[spacetribe]

К холивару готовы? :)

[ISVir]

Я высказал свое мнение, на вселенскую истину не претендую ;)

[ISVir]

P.S. Парсер съел табуляцию…

[spacetribe]

Вас зарезал злобный хабрапарсер :)

[coldFlame]

Вы извините, но в этом случае еще приятнее просто

Hello

[ISVir]

В cli это тоже у вас выполнится?

[kurokikaze]

Да. Только что проверил. Ну еще путь к интерпретатору можно добавить.

[khizhaster]

(defined($style{compact}) && defined($style{smart})) || warn «Bad style»;

[Meneldor]

Для control flow рекомендуется использовать or и and вместо || и && :).

[Meneldor]

defined $style{compact} and defined $style{smart} or warn 'Bad style';

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

[khizhaster]

Вот тут есть спорные моменты. Некий Ларри Уолл советует расставлять скобки «побольше». Хотя без скобок мне тоже нравится больше :) А про and/or, имхо, в данном случае дело вкуса. У && || приоритет выше, но в данном случае это не играет роли. Кому как нравится :)

[Meneldor]

А можно ссылочку? Вот документ от меня по теме:
perldoc.perl.org/perlstyle.html
А конкретно: «Omit redundant punctuation as long as clarity doesn't suffer.»

[khizhaster]

Ошибся, это он о других скобочках, запамятовал совсем
books.google.com/books?id=ezqe1hh91q4C&printsec=frontcover&hl=ru
вот тут, на странице 264

[Meneldor]

И даже там я не увидел призыва ставить побольше скобок — любых :).

[nooze]

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

[Jama]

Если первый вариант, это что-то типа такого:

$string = trim(str_replace($pattern, $replacement, preg_replace($preg_pattern, $preg_replacement, $string)));

То я — за второй.

[spacetribe]

Да, это укладывается в рамки первого варианта.

[Jama]

А с другой стороны, если тот-же код написать на питоне:

str = re.sub(re_pattern, re_replacement, str).replace(pattern, replacement).strip()

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

[termt]

Если нормально отформатировать имхо вполне читаемо, но перегибать с такими вложениями не стоит.

$string = trim(
	str_replace(
		$pattern, 
		$replacement, 
		preg_replace(
			$preg_pattern, 
			$preg_replacement, 
			$string
		)
	)
);

[alkk]

А вот теперь представьте, что вам в процессе отладки захотелось посмотреть, что вернул preg_replace…

[Paul]

Если бы это был С/С++ и MS VS, то step in preg_replace, step out и в окошке Auto вы бы увидели, что вернула функция, из которой вы вышли. Отладчики PHP так не умеют?

[alkk]

Не в курсе, я не пишу на PHP. Должны, по идее.

В любом случае, я за такие конструкции бью по рукам. Как и за if-ы без скобок, chained calls (method1().method2().method3()), присвоения в if-ах и вообще различный obscured и error-prone код.

[mx2000]

да без проблем:

…
$debug_value = preg_replace()
…

echo $debug_value;

[alkk]

т.е. код станет вот такой?

$debug_value = preg_replace(
$preg_pattern,
$preg_replacement,
$string
)

$string = trim(
str_replace(
$pattern,
$replacement,
$debug_value
)
);

А после того, как посмотрели — вернете все обратно?

И чем это лучше, чем сразу вынести результаты в переменные?

[mx2000]

зачем же так? Код станет вот таким:

$string = trim(
str_replace(
$pattern,
$replacement,
$debug_value = preg_replace( // look here
$preg_pattern,
$preg_replacement,
$string
)
)
);

[alkk]

Да, уже проверил.

Жуть.

[gooddy]

по настроению

[Antikiller]

Когда увеличение размера кода мало влияет на производительность программы — описываю всё подробно. Иногда приходится перечитывать собственные исходники через пару лет, и тут лаконичность пониманию не способствует. Внедрение пары временных переменных в таком случае — приемлимо, я считаю.
А вот когда приходилось писать на ассемблере (это было давно и неправда), тут никаких лишних строчек не допускалось; для асма работает правило «чем короче, тем понятней».

[Bambr]

Ключевое слово — чтобы все было понятно и не вызывало вопросов ни у тебя, ни у членов команды.

[TonyClifton]

«Лаконичный» — это когда одну строку всё через точку с запятой? :-)

[spacetribe]

Отчасти — вплоть до комментариев. Но в разумных, разумеется, пределах.

[sgzmd]

Хорошо красиво написаный код удобно поддерживать. Особенно если его написал не ты. Особенно если пять лет назад. Особенно если документации нет, как нет и человека, который это писал, а это все надо срочно править.

[sgzmd]

… и плевать что в исходнике много «лишних» вроде бы строк.

[spacetribe]

А скроллить не надоедает? Особенно если на нетбуке каком…

[LoneCat]

Большинство современных IDE имеют возможность сворачивания кода, а без нее даже лаконичный код читать не шибко-то удобно.

[Incite]

Заниматься программированием на нетбуке — это извращение.

[VasilioRuzanni]

А где же вариант «где мало строк, но каждая из них несет полезную нагрузку и выполняет оптимум (а то и минимум) возможных операций»? Ну или «код, который выполняет ровно то, что нужно»

[spacetribe]

Вам в первый вариант, он это, по идее, и подразумевает…

[VasilioRuzanni]

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

[grumbler_chester]

Который соответствует code convention. Я программы не для себя пишу, а для людей, и единый стандарт оформления сильно облегчает нам всем жизнь.

[LoneCat]

Люблю все красиво оформить и подробно расписать, причем фанатично предан своей позиции, я считаю что некрасивый, неудобный для прочтения код, по определению не может хорошо работать, так как шанс допустить в нем ошибку на порядок выше. Да и вообще должно-же быть в нашей профессии что-то красивое… :P

[roTuKa]

К слову, «скрупулёзный». Это — очень распространённая ошибка.
За него и проголосовал.

[spacetribe]

Настолько распространенная, что впору менять грамматику. :(

[roTuKa]

Нужно в школе учиться скрупулёзнее, а не грамматику менять.

[khayrov]

Как тут уже сказали, принятые в проекте правила стиля прежде всего.
Краткость — не самоцель. Но красивый и понятный — не значит раздутый.
Я стараюсь минимизировать плотность побочных эффектов. Если цепочка из нескольких вызовов описывает понятный data flow, значит место ей в одном операторе. Эмпирический критерий: у промежуточного значения должно быть понятное и быстро придумываемое название, чтобы его имело смысл вынести в переменную.
В языках, где с выражением подобных абстракций туго, придерживаюсь verbose стиля.
В общем, стиль должен быть адекватен возможностям языка. Возможностям команды тоже, но это уже другой вопрос.

[johny]

Как-то привык уже оформлять код относительно красиво )
Вместо табуляции использую два пробела. Не знаю, хорошо ли это, но читается достаточно удобно.

[LoneCat]

А я наоборот отказался от двойного пробела в пользу табуляции, так как табуляция — это все-таки специально предназначенный для этого символ, который к тому-же в большинстве современных редакторов кода можно настроить самостоятельно, например на те-же два пробела, это способствует тому чтобы у другого программиста, открывшего этот код, он отображался чуточку ближе к его собственным предпочтениям.