Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 55

тогда другие разработчики будут форматировать ваш код десятилетиями

Один хоткей в решарпере, он по дефолту именно так и выравнивает linq по точкам.


добавили несколько пробелов на пустой строке (чтобы понять разницу, выделите 5ю строку)

То же самое и здесь: тот же хоткей, который просто въедается в автоматизм.


Время ценно, тратить время разработчиков на то, чтобы вручную форматировать код — в 2020 году это нонсенс.

Всего голосов 7: ↑7 и ↓0+7

Хоткей не нужен. Автоформатирование должно происходить при сохранении.

Всего голосов 5: ↑4 и ↓1+3

Ага, а потом в одной репе встречаются два разработчика с разными настройками форматирования, и...


Ещё весело бывает, когда кто-то заботливо добавлял пробелы чтобы получить табличное форматирование, а потом пришла IDE, и при сохранении автоматически всё испортила.

Всего голосов 4: ↑3 и ↓1+2
НЛО прилетело и опубликовало эту надпись здесь

Откуда они там встречаются? Ревьювер должен дать по шапке тому, кто отключил гитхуки при коммите и залил фигню.


Все настройки форматирования и линтеров в проекте лежать должны.

Всего голосов 4: ↑3 и ↓1+2
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Если вам понадобилось менять такой код — вам, скорее всего, всё равно понадобится менять все строки сразу.

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь

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

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
$x2 =  $x1 * cos($angle) + $y1 * sin($angle);
$y2 = -$x1 * sin($angle) + $y1 * cos($angle);
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь

Redundand else детектед:


if (isValid) 
{ 
    _unitOfWork.Save();
    return true; 
} 
else 
{ 
    return false; 
}

Лучше, т.к. экономит горизонтальное пространство для блока else:


if (isValid) 
{ 
    _unitOfWork.Save();
    return true; 
}

return false;
Всего голосов 11: ↑7 и ↓4+3
Тогда уж:
if (isValid) 
{ 
    _unitOfWork.Save();
}

return isValid;
Всего голосов 20: ↑19 и ↓1+18

Хороший вариант, особенно когда есть понимание, что ничего больше в блоках добавляться не будет. Версия которую я предложил — та что решарпер подсказывает с включенной Redundand else

Всего голосов 1: ↑1 и ↓0+1
Это в любом случае хороший вариант. А если в будущем в блоках нужно будет что-то добавлять — то тогда в будущем и будет изменена схема с if-else-return блоками.
Всего голосов 1: ↑1 и ↓0+1

Должны быть так
return (isValid)? _unitOfWork.Save(): false;
Функция должна вернуть результат своей работы. Иначе это лотерея.

Всего голосов 9: ↑2 и ↓7-5
Не делайте так. Даже асм читабельнее.
Впрочем, C++ уверенно развивает традиции.
Комментарий пока не оценивали0
return isValid? _unitOfWork.Save(),true: false;
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
return (isValid? _unitOfWork.Save(): (void)0), isValid;
Комментарий пока не оценивали0
80 символов в строке – это рекомендуемый стандарт на текущий момент.

На какой момент? На 1985г?
Лично у меня влезает 360 символов на экран. Открываю 2-3 исходника.

var result =
(condition1 && condition2) ||
condition3 ||
(condition4 && condition5);

Предполагается что это хороший стиль? Это нечитабельное месиво.
Напротив, «неправильный» пример аккуратный и читабельный.

Всего голосов 23: ↑18 и ↓5+13
Лично у меня влезает 360 символов на экран.
Во-первых, это лично у вас. Во-вторых, влезать может хоть 500, читать-то это как?
Всего голосов 11: ↑10 и ↓1+9

На телефоне не влезает 360. А 80 норм.

Всего голосов 8: ↑2 и ↓6-4

Для мержа придется найти экран на 720 символов.

Всего голосов 8: ↑8 и ↓0+8

(сарказм)


Легко! Берете 2 экрана и сравниваете


Но пока я не придумал, что делать с разработчиками, у которых 2 экрана, поэтому они пишут код в 720 символов сразу
Всё-таки 4 монитора для этого понадобится


(сарказм офф)


Мне кажется основная проблема длинного текста не в том, что он на экран не влезает, а в том, что куча всего смешивается в одну строку и это становится трудночитаемым. Например, пример 2 из статьи, если это всё смешать в одну строчку, читать становится гораздо труднее (даже если это поместится на экран)

Всего голосов 3: ↑3 и ↓0+3
НЛО прилетело и опубликовало эту надпись здесь

Надеюсь это была шутка…

Комментарий пока не оценивали0
Не отстаивая именно 80, замечу, что при мерже на экране бывают сразу три версии файла. И три по 80 — это уже 240. А так мне тоже кажется, что при нынешних мониторах допустимо поднять это ограничение до 120 символов.
Комментарий пока не оценивали0
сейчас некоторые переходят на 100 и 120
Комментарий пока не оценивали0
80 символов в строке – это рекомендуемый стандарт на текущий момент. Это позволяет вам держать концентрацию разработчика, когда он читает ваш код. Более того, вы можете открыть два документа одновременно на одном экране когда это нужно, и у вас останется место для обозревателя решений.

да хватит уже тыкать палкой этот стандарт времен DOS-а. что хорошего рубить логику в лапшу. из-за подобных стандартов, чтобы не разбивать строки, люди начинают сокращать идентификаторы, превращая исходники в ребус. если уж нужно открыть 2 документа, то можно включить перенос строк или разбить экран по горизонтали.
120-130 символов норм.

Всего голосов 19: ↑18 и ↓1+17
НЛО прилетело и опубликовало эту надпись здесь

Я думаю — просто магия ровных цифр, так я видел и 100 и 120. Много уже проектов в кодстайле прописали 100 символов, мммм… навскидку: https://github.com/airbnb/javascript

Комментарий пока не оценивали0
Я думаю — просто магия ровных цифр

для программистов ровная цифра — это 128 :)


https://github.com/airbnb/javascript

какой веселый кодстайл, не рекомендует начинать имена свойств с подчеркивания

Всего голосов 8: ↑8 и ↓0+8

127. потому что за ней может идти -128.

Всего голосов 2: ↑1 и ↓10
Вы им только не говорите, что сейчас можно еще подключать несколько мониторов.
Всего голосов 2: ↑2 и ↓0+2

Это не времена DOS-а. Это гораздо древнее. Ещё перфокарты были по 80 колонок. Этакое физическое ограничение длины строки.

Всего голосов 3: ↑3 и ↓0+3
Пример №2 лучше писать так:
var result = 
    (condition1 && condition2)
    || condition3
    || (condition4 && condition5)
;

Оно и читается легко и при изменении в diff попадёт адекватный лог. Добавив или удалив условие мы в diff-е получим меньше мусора.
Всего голосов 10: ↑10 и ↓0+10

Проблема будет когда в таком выражении условия в несколько строк кто-то отредактирует последнюю, а другой первую. У обоих все работает. Конфликта при мерже нет, но условие уже сломано.

Всего голосов 4: ↑1 и ↓3-2
С этим вариантом одно плохо: не для всех языков подходит(замечу, что тэга С/С++ у статьи нет, значит она про все языки). А именно для языков, которые считают, что точка с запятой не нужна. Вот, скажем, для Go такой вариант будет как раз вредным советом, ибо компилятор тут же выкинет нечто вроде(Go не понимает тут, где строка кончается):

./prog.go:10:10: syntax error: unexpected ||, expecting }
Комментарий пока не оценивали0

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

Всего голосов 3: ↑3 и ↓0+3
var result = 
    (condition1 && condition2) || 
    condition3 || 
    (condition4 && condition5);

я бы разбил так:


var result =  condition3 
          || (condition1 && condition2) 
          || (condition4 && condition5);

Логический оператор в начале строки лучше читается

Всего голосов 8: ↑7 и ↓1+6

Только вот переставлять условия местами я бы не стал:


var result = (condition1 && condition2)
     || condition3
     || (condition4 && condition5);

Вдруг это хитрые свойства с побочными действиями?

Всего голосов 1: ↑1 и ↓0+1

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

Комментарий пока не оценивали0

В performance-critical коде первыми поставили бы наиболее быстро проверяемые условия (например, проверить булевские значения), а в конец — более медленные (например, сравнение строк), так что универсального подхода тут нет.

Всего голосов 1: ↑1 и ↓0+1
Переставлять условия вообще нельзя: если значение логического выражения определяется уже по значению первого операнда (true для ||, false для &&), то второй операнд не вычисляется вообще (по крайней мере, в C#, на котором написаны примеры, это однозначно так). То есть, действует правило неполного вычисления, и в C# им пользуются весьма часто — например, сначала идет проверка ссылки на объект на !=null, а потом, через && — проверка значения поля или свойства (да, про операцию ?. я в курсе, но она появилась не так давно, много кода было написано до того).
Всего голосов 2: ↑2 и ↓0+2
Для Go только первый вариант рабочий. Так что, сначала надо определиться с языком, а потом уже переформатировать :)
Комментарий пока не оценивали0
Ещё один вредный совет:
Если вы пишете под Android, используйте m для префиксов членов класса, например mIsValid, ведь сразу становится понятно, что это field, а не variable /s
На самом деле, это «m» — просто жесть. Пошло оно с тех времён, когда core команда не могла нормально использовать IDE, поскольку Eclipse не осиливал загрузить такой большой объём кода в себя. Потом пришла IDEA/Android Studio, которая уже нормально осиливала, но ретрограды из гугла, которые могут в уме инвертировать бинарное дерево не осилили уже саму IDE, и поэтому пишут вот в таком стиле до сих пор.
А самое печальное — что они же пишут доки, откуда этот «m» разносится по проектам 3rd-party разработчиков, которые понятия не имеют, зачем оно нужно, но тупо копипастят, потому что ж «гугол решил, а там не дураки работают».

P.S. Те, кому до сих пор кажется, что «там не дураки работают» — посмотрите внимательно код AOSP Launcher, такое ощущение, что туда как в Спарте сбрасывают самых слабых разработчиков. А это, по сути, Core Android.
Всего голосов 3: ↑3 и ↓0+3

Это и других языков касается. Меня очень увидило, когда я установил Rider, и он начал ругаться, что у меня имена полей не соответствуют кодстайлу по умолчанию. По его мнению, все поля должны начинаться с "_". Зачем?

Всего голосов 1: ↑1 и ↓0+1
Способ форматирования фигурных скобок в определениях функций, который мне очень нравится, но я никогда его не использую.
Smth foo(int par)
{   some code
    more code
    return smth;
}
Smth bar(int par)
{   some code
    more code
    return smth;
}
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr