Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Давным давно, когда люди забивали гвозди использую ASM и готовили DOS на Quick C...
О чём это я? А!
Да, есть такое понятие как "Коммерческий код". Это некая форма стилизации кода для лучшего восприятия кода мозгом.
Такой вид форматирования сильно облегчает понимание сути описанного в коде алгоритма.
К сожалению о нём забили, а многие даже и не слышали.
Данный вид форматирования был создан группой людей (из FidoNet). Использовался он для написания коммерческих программ, которые продаются вместе с исходным кодом.
На сегодняшний день почти все используют PSR и не задумываются о таких вещах, как скорость восприятия чужого кода на интуитивном уровне.
Вот и хочу Вам... рассказать... или напомнить... или предложить стиль кода "Коммерческий".
Чем он отличается и какие правила он применяет:
Большинство пишет код так:
class Text {
const TEST = 1;
public static $test = '';
public $filename = '';
public $name = '';
private $a;
protected $b;
public functuion getA() {
if(self::$test == self::TEST) {
return $this->a;
}
/* Или такой вариант
if (self::$test == self::TEST) {
return $this->a;
}
*/
return null;
}
}
Коммерческий код выглядит так:
class Text
{
// Константы всегда в начале
const TEST = 1;
// Затем всегда паблик
public $filename = '';
public $name = '';
// Потом протектед
protected $b;
// и приватные
private $a;
// Далее так же и статические
public static $test = '';
// Такое же правило относится и к методам
public functuion getA()
{
// Обязательно if( пробел условие пробел )
// if( - мозг воспринимает лучше чем if (
// условия типа
// if(!$data) или if (! $data)
// воспринимается хуже чем if( !$data )
if( self::$test == self::TEST ) {
return $this->a;
}
return null;
}
}
все переменные и свойства в snake_case
все методы в lowerCamelCase
все функции (процедуры) в snake_case
все имена классов в UpperCamelCase
описание последовательности вызова методов:
return $users->default()
->actived()
->get();
а не:
return $users->default()->actived()->get();
все простые условия типа:
if( self::$test == self::TEST ) {
return $this->a;
}
return null;
должны описываться так:
return ( self::$test == self::TEST ) ? $this->a : null;
почему скобки? для визуального отделения условия от логики;
При длинных вариантах:
return ( self::$test == self::TEST ) ? $users->default()->actived()->get() : $users->actived()->get();
Надо писать так:
return ( self::$test == self::TEST )
? $users->default()->actived()->get()
: $users->actived()->get();
Это будет восприниматься быстрей и понятней.
Я часто встречаю записи такого вида и они просто неудобно-читабельны:
return $this->response($this->presenter->full($infraction));
или:
$infraction->users()->attach($original->users->pluck('id'));
И исправляю их на:
return $this->response(
$this->presenter->full(
$infraction
)
);
и:
$infraction->users()
->attach(
$original->users
->pluck('id')
);
Так воспринимается куда более быстрей.
Много всего, но Коммерческий код воспринимается всеми программистами (и профи и новичками) с одинаковой скоростью и лёгкостью.
Что скажете?
Не в сети
Скажу следующее:
Зачем было исковеркивать PSR-1/PSR-2 и обзывать эту смесь "коммерческим" кодом?
Собственно, по код стайлу можно сразу понять какой культурой обладает автор этих строк.
PSR выглядит приятно, я всегда использую эти стандарты (читай - соглашения) для автоформатирования и руками правлю лишь шероховатости.
Так-же отмечу следующее:
Laravel, исходный код ларавела, полностью соответствует соглашениям PSR.
Мы, как разработчики, используя Laravel, так-же и следуем "культуре" ларавела, которая отражается в том, как мы оформляем свой код на всех уровнях его восприятия.
Иметь другой код-стайл, это как писать на ruby, но ставить точку с запятой в конце строки (заметка - никто из разработчиков ruby не ставит точку с запятой в конце строки, но, сам ruby не запрещает тебе ее ставить, компилятор "схавает").
Изменено covobo (10.11.2017 14:18:47)
Не в сети
Зачем было исковеркивать PSR-1/PSR-2 и обзывать эту смесь "коммерческим" кодом?
Коммерческий код появился за долго до появления всяких PSRов и над стилизацией работали куча оченб грамотных людей. В то время как PSR появился позже и много было заимствовано из коммерческого кода с изменениями.
Коммерческих код не использовался на PHP никогда... только на C (C++) и Pascal'е.
И на сколько я знаю, PSR был принят сообществом только потому, что нужно было стандартизировать стилизацию кода на PHP. И принят он был чисто условно на пальцах... типа "А давайте так писать?", а давайте!
Над коммерческим кодом работали и доводили до идеала. Над PSR никто не работал... просто притянули за уши с других языков... по большей части с C++.
Я программирую ещё с 1987 года на С и C++, на Delphi с 1995. И был владельцем BBS (Maximus 3.0 с фидо ретранслятором)... и об интернете тогда ещё никто "слыхом не слыхива"... я не говорю уже о PHP и PSR.
Но то, что я вижу сейчас в PSR меня удивляет.
Вот и хочется показать людям более понятную стилистику, которая "слизывается мозгом" и не приходится напрягать глаза и мозги, что бы понять, что же там написано.
Не в сети
Я программирую ещё с 1987 года на С и C++, на Delphi с 1995. И был владельцем BBS (Maximus 3.0 с фидо ретранслятором)... и об интернете тогда ещё никто "слыхом не слыхива"... я не говорю уже о PHP и PSR.
Не сомневаюсь в твоем "гуру".
Перечитай пожалуйста мое сообщение (так вышло, что я отредактировал его в момент написания твоего комментария).
Вопрос о стилистике кода, это достаточно большой вопрос, который выходит за рамки этого форума, как минимум потому, что мы не увидим здесь мнения создателей PSR.
Я поддерживаю некоторые твои предложения, например - обрамлять условие скобочками (тернарный оператор), но, в целом отношусь негативно.
Но, если вдруг, ты добьешься изменений в PSR, для меня это будет не больше, чем применить новый конфиг в IDE, ибо что PSR, что твои предложения - все это прикольно и по своему помогает воспринимать код.
Я не могу признать, что сейчас код читается хреново.
Не в сети
Я не буду спорить... но вот пример из фреймворка Laravel:
public function url($path)
{
$adapter = $this->driver->getAdapter();
if (method_exists($adapter, 'getUrl')) {
return $adapter->getUrl($path);
} elseif ($adapter instanceof AwsS3Adapter) {
return $this->getAwsUrl($adapter, $path);
} elseif ($adapter instanceof RackspaceAdapter) {
return $this->getRackspaceUrl($adapter, $path);
} elseif ($adapter instanceof LocalAdapter) {
return $this->getLocalUrl($path);
} else {
throw new RuntimeException('This driver does not support retrieving URLs.');
}
}
В коммерческом виде было бы так:
public function url( $path )
{
$adapter = $this->driver
->getAdapter();
if( method_exists($adapter, 'getUrl') ) {
return $adapter->getUrl( $path );
} else if( $adapter instanceof AwsS3Adapter ) {
return $this->getAwsUrl( $adapter, $path );
} else if( $adapter instanceof RackspaceAdapter ) {
return $this->getRackspaceUrl( $adapter, $path );
} else if( $adapter instanceof LocalAdapter ) {
return $this->getLocalUrl( $path );
} else {
throw new RuntimeException(
'This driver does not support retrieving URLs.'
);
}
}
Разве так не лучше?
Не в сети
Без подсветки кода действительно кажется, что второй вариант лучше.
А с ней оба варианта можно критиковать, но читаются одинаково легко
http://prntscr.com/h8nf68
http://prntscr.com/h8nftk
(я использую 14-ый размер шрифта Menlo)
Изменено covobo (10.11.2017 15:01:35)
Не в сети
Мне это напоминает...
- "Я езжу на ВАЗе и мне не нравятся ваши Мерседесы! Наши автомобили лучшие в мире!"
Но!
- "Если кормить волка овсом всю жизнь, он будет считать, что это лучшая еда. Но стоит ему попробовать мясо, он больше не будет есть овёс!"
Не в сети
Очень холиварную тему вы подняли.
По совпадению, я тоже начинал активно программировать с Delphi (больше пяти лет ежедневного общения с Delphi 5-7), а до этого написал прилично кода для TP. Тем не менее, я считаю, что стиль кода вторичен, если не выходить за рамки адекватности (соблюдать отступы, единообразие, какое бы оно ни было, не писать несколько выражений в одну строку и так далее). PSR и код большинства популярных библиотек этому требованию вполне соответствуют, пусть даже у них часто разный code style.
(Что характерно, код самого Вирта просто кошмарен.)
PROCEDURE Install* (T: Task);
VAR t: Task;
BEGIN t := PrevTask;
WHILE (t.next # PrevTask) & (t.next ff T) DO t := t.next END;
IF t.next = PrevTask THEN T.next := PrevTask; t.next := T END
END Install;
Работа программиста - это работа с текстом и восприятие кода. Этот навык оттачивается так же, как умение писать рабочий код вообще. Если у тебя 20+ лет стажа и ты брюзжишь о том, что скобочки не там поставили - у тебя какие-то проблемы. ИМХО.
Вот пара примеров:
// Далее так же и статические
public static $test = '';
Забавно, а для меня логичнее всегда ставить статические члены в начале класса. Почему? Потому что декларация class X - статическая конструкция сама по себе; кроме того, именно статические методы интересны в первую очередь тому, кто будет использовать класс (с этой точки зрения __construct - полу-статический метод и я его ставлю в начале методов экземпляра).
// if( - мозг воспринимает лучше чем if (
Вот это (как и другие "мозг воспринимает лучше") очень-очень спорно. Я if( воспринимаю как неряшливое письмо. if - не функция, это отдельное ключевое слово.
все функции (процедуры) в snake_case
Зачем мешать два стиля в одном? snake_case - это Си, camelCase - это Паскаль/Java. Банально проще набирать код, когда ты знаешь, что все идентификаторы в одном стилевом регистре, и изменения проходят проще (поле становится методом или наоборот). КОН_СТАНТЫ - исключение, и хорошо, что обычно они значительно реже используются.
Коммерческий код появился за долго до появления
работали куча оченб грамотных людей.
Коммерческих код
И на сколько я знаю
Есть мнение, что если человек пишет тексты на естественном языке с ошибками, то это также ухудшает его восприятие, скорость и так далее. Вы так не думаете?
Я к чему. Первично - это логика и содержание. Пока стиль не мешает их восприятию (см. код Вирта), то он вторичен - как в программировании, так и в человеческих языках.
- "Я езжу на ВАЗе и мне не нравятся ваши Мерседесы! Наши автомобили лучшие в мире!"
— Мне не шашечки, а ехать.
Не в сети
Есть мнение, что если человек пишет тексты на естественном языке с ошибками, то это также ухудшает его восприятие, скорость и так далее. Вы так не думаете?
Да, в Ваших словах есть львиная доля правды. Но в данный момент мы пишем используя клавиатуру, что уже является не вполне естественным и конечно имеют место быть рефлекторные огрехи.
И в Нашем Великом Русском Языке очень много не естественных для нашего языка слов, позаимствованных у других народов с совсем другой фонемой.
Первично - это логика и содержание
Абсолютно с Вами согласен! Но! Если всё слитно и смазано написано, воспринять логику и содержание сложно.
А вот когда всё "удобно-читаемо", понимать описанную логику и содержание куда приятней и проще.
Это как говорить внятно, четко и громко вместо шепеляво, быстро и тихо.
Забавно, а для меня логичнее всегда ставить статические члены в начале класса.
В данном случае соглашусь с Вами. Но я говорю о коммерческом варианте кода, который был описан давно.
С другой стороны... всегда описываются в начале первично-важное, а затем остальное.
В классах первичным считаются (на сколько я знаю) локальные методы и свойства, а уж затем наследуемые и статика.
Но и тут можно спорить вечно.
PROCEDURE Install* (T: Task);
VAR t: Task;
BEGIN t := PrevTask;
WHILE (t.next # PrevTask) & (t.next ff T) DO t := t.next END;
IF t.next = PrevTask THEN T.next := PrevTask; t.next := T END
END Install;
Вот честно... ключевые слова в верхнем регистре мало встречал в Delphi... возможно в начальных версиях и попадалось такое безобразие... но с 3й версии точно не попадалось... даже в сторонних компонентах.
Вот так обычно было:
function Encrypt(const InString: string; StartKey, MultKey, AddKey: Integer): string;
var
i: Byte;
begin
Result := '';
for i := 1 to Length(InString) do
begin
Result := Result + Char( Byte(InString[ i ]) xor (StartKey shr 8) );
StartKey := ( Byte(Result[ i ]) + StartKey ) * MultKey + AddKey;
end;
end;
Изменено Cruide (10.11.2017 18:05:15)
Не в сети
Мое мнение такое: следуй договоренностям фреймворка/языка, на котором пишешь (PSR-2 и пр.). Даже если они тебе не нравятся. При таком подходе, в итоге, выигрывают все.
Не в сети
Помоему автор пишет какую то дичь. Тернарный оператор в несколько строк уж точно не лучше чем if?
Не в сети
Тернарный оператор в несколько строк уж точно не лучше чем if?
На самом деле лучше, т.к. if не может возвращать результат (языки, где это не так, вроде Ruby, в расчет не берем). А читается вполне себе хорошо, если нормально расставлять отступы. С if же получаем if + временную переменную, а в случае с Pascal/C - еще строку, где эта переменная объявляется.
Не в сети
Страницы 1