Академия плохого кода: переводы строк, пробелы и отступы

[questor]

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

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

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

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

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

[Dolios]

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

[mayorovp]

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

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

[Dolios]

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

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

[DistortNeo]

В идеале код вообще может автоформатироваться под каждого разработчика.

[mayorovp]

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

[mayorovp]

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

[mayorovp]

$x2 =  $x1 * cos($angle) + $y1 * sin($angle);
$y2 = -$x1 * sin($angle) + $y1 * cos($angle);

[questor]

Redundand else детектед:

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

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

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

return false; 

[shai_hulud]

Тогда уж:

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

return isValid; 

[questor]

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

[PrinceKorwin]

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

[granvi]

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

[mistergrim]

Не делайте так. Даже асм читабельнее.
Впрочем, C++ уверенно развивает традиции.

[Harkonnen]

return isValid? _unitOfWork.Save(),true: false;

[Harkonnen]

return (isValid? _unitOfWork.Save(): (void)0), isValid;

[beeruser]

80 символов в строке – это рекомендуемый стандарт на текущий момент.

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

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

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

[mistergrim]

Лично у меня влезает 360 символов на экран.

Во-первых, это лично у вас. Во-вторых, влезать может хоть 500, читать-то это как?

[lamerok]

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

[a1ex322]

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

[bugy]

(сарказм)

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

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

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

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

[bugy]

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

[martin_wanderer]

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

[sys_int64]

сейчас некоторые переходят на 100 и 120

[CoolCmd]

80 символов в строке – это рекомендуемый стандарт на текущий момент. Это позволяет вам держать концентрацию разработчика, когда он читает ваш код. Более того, вы можете открыть два документа одновременно на одном экране когда это нужно, и у вас останется место для обозревателя решений.

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

[CoolCmd]

линус — мужик!
но я так так и не понял, с какого потолка они взяли цифру 100.

[questor]

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

[CoolCmd]

Я думаю — просто магия ровных цифр

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

https://github.com/airbnb/javascript

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

[khajiit]

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

[Harkonnen]

А так же поэтому

[hkolop]

Вы им только не говорите, что сейчас можно еще подключать несколько мониторов.

[kukovik]

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

[yarkov]

Пример №2 лучше писать так:

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

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

[PrinceKorwin]

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

[VMarkelov]

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

./prog.go:10:10: syntax error: unexpected ||, expecting }

[alexxz]

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

[Sklott]

deleted

[Gordon01]

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

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

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

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

[DistortNeo]

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

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

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

[Gordon01]

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

[pankraty]

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

[mvv-rus]

Переставлять условия вообще нельзя: если значение логического выражения определяется уже по значению первого операнда (true для ||, false для &&), то второй операнд не вычисляется вообще (по крайней мере, в C#, на котором написаны примеры, это однозначно так). То есть, действует правило неполного вычисления, и в C# им пользуются весьма часто — например, сначала идет проверка ссылки на объект на !=null, а потом, через && — проверка значения поля или свойства (да, про операцию ?. я в курсе, но она появилась не так давно, много кода было написано до того).

[VMarkelov]

Для Go только первый вариант рабочий. Так что, сначала надо определиться с языком, а потом уже переформатировать :)

[artem322]

Ещё один вредный совет:
Если вы пишете под Android, используйте m для префиксов членов класса, например mIsValid, ведь сразу становится понятно, что это field, а не variable /s
На самом деле, это «m» — просто жесть. Пошло оно с тех времён, когда core команда не могла нормально использовать IDE, поскольку Eclipse не осиливал загрузить такой большой объём кода в себя. Потом пришла IDEA/Android Studio, которая уже нормально осиливала, но ретрограды из гугла, которые могут в уме инвертировать бинарное дерево не осилили уже саму IDE, и поэтому пишут вот в таком стиле до сих пор.
А самое печальное — что они же пишут доки, откуда этот «m» разносится по проектам 3rd-party разработчиков, которые понятия не имеют, зачем оно нужно, но тупо копипастят, потому что ж «гугол решил, а там не дураки работают».

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

[DistortNeo]

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