-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.3. Выравнивание присвоений переменных и элементов массива #18
Comments
Спасибо за комментарий, я все больше склоняюсь к тому, что конкретно этот пункт вовсе стоит удалить из рекомендаций. Этот пункт слишком спорен и субъективен. Ваш же пример в двух видах оформления, мне субъективно читать проще с отступами. Физически проще за счет того, что есть 2 колонки, в зависимости от того, что мне надо (переменная/значение) - я читаю правую, или левую колонку. В случае, когда отступов нет - визуально нужно разделять каждую строку. Объективный минус отступов в том, что в коммит попадут помимо изменяемых строк еще и отформатированные, это усложняет code review. Возможно вы сталкивались с плагинами для phpStorm, которые могут визуально добавлять отступы, при этом не менять исходный код? $user_access_token = $user_access_token_storage->get();
$i = 1;
$has_promote_articles = false;
$result = [];
$ids = [];
$categories = [];
$user_access_token = $user_access_token_storage->get();
$i = 1;
$has_promote_articles = false;
$result = [];
$ids = [];
$categories = []; |
Я не автор, но попробую поспорить)
Тут плохое оформление - дело десятое, тут код: substr($query, 0, strrpos($query, '/')). ($isChild ? '/' : '//').$el - нечитаемый абсолютно. Отсюда и в 120 упёрлись А вот тут - частично согласен. Не надо принудительно выравнивать сильно разные строки. Лучше наоборот разделить их пустой строкой, чтобы не слипалось визуально
|
В принципе можно и дополнить этот пункт комментарием @VladReshet , получится что-то типа такого $user_access_token = $user_access_token_storage->get();
$has_promote_articles = false;
$result = [];
$categories = [];
$i = 1;
$ids = []; или такого $user_access_token = $user_access_token_storage->get();
$has_promote_articles = false;
$i = 1;
$result = [];
$ids = [];
$categories = []; |
Все верно. Именно поэтому этот способ и придумали и это основной аргумент в пользу использования этого способа форматирования. Но проблема в том, что нам не нужны отдельно названия переменных и не нужны отдельно абстрактные значения. Нам нужны связанные воедино переменные и их значения. Добавление отступов разрывают эту связь и усложняют чтение. Для того, что бы лучше видеть связь приходится ставить курсор на интересующую нас строку, что бы подсветить ее. Аналогичная проблема есть и в классических таблицах и есть вполне распространенные решения этой проблемы. |
@peter-gribanov убедили |
1.3. Выравнивание присвоений переменных и элементов массива
Довольно спорное решение. Я бы сказал вкусовщина. Я когда-то очень давно применял этот подход и результат мне не понравился. Улучшается читаемость только если название переменных (ключей массива) и присваиваемые им значения имеют примерно одинаковую длину.
Если разница в длине значительная, то образуются большие дырки которые осложняют чтение кода как в вашем примере:
Другой утрированный пример более наглядно демонстрирующий проблему.
Ещё добавление пустых отступов увеличивает длину кода объявления переменной и мы раньше упремся в лимит в 120 символов на строку и нам раньше потребуется разбивать код на строки, что приведет к увеличению длинны метода и ухудшению читаемости из-за распухших методов и мы раньше упремся в ограничение длинны метода.
Вот еще кусок кода взятый из реального не моего проекта отформатированный в соответствии с вашим требованием. Отступы в начале строки нужны потому, что код имеет глубокую вложенность.
Так диссонанс будет нагляднее
Пройдясь несколько раз по всем этим граблям, я заметил, что читаемость улучшается в крайне малом числи случаем. В большинстве случаев читаемость ухудшается и появляются дополнительные проблемы.
Я не помню, что бы мне на GitHub попадался хотя бы один проект который бы использовал такое форматирование, что как бы тоже наводит на мысль о несостоятельности решения.
The text was updated successfully, but these errors were encountered: