a=3; b=5
нормально питон отрабатывает точку с запятой, другое дело что можно и без них.
первое время больше парило что циклы и т.п. отделяются табуляцией без {}
раскрыть ветку (43)
А меня как раз это вообще не парило, ещё со школы привык табуляцией выделять блоки. Скорее при частой смене языков парит разная сигнатура стандартных функций - например, len(...) или .length(), map(...) или .map(...) и т.п. А ещё когда к проекту раз в пол года возвращаешься, без типизации сложновато.
раскрыть ветку (1)
Заставили нас тут писать курсач на Питоне. Прикольный язык, но мне в нём не хватает строгости.
Определяю переменную в начале программы, напишу десяток другой строчек кода, а потом думаю, что вообще было в этой переменной и как к ней обращаться.
Или те же циклы. Если бы я в школе начинал изучать Питон, а не Паскаль, то местные while и for (который на самом деле работает как "foreach") пришлись бы очень кстати, т.к. они максимально логичны. Но я уже привык к си-шным for, while и foreach, и оформлять цикл перечисления в while мне неудобно. Я 2 раза вешал свой курсач в бесконечный цикл, потому что забывал увеличивать счетчик в конце while...
В итоге, вышел говнокод ещё больший, чем обычно (из-за того, что язык я изучал прям в процессе написания кода), но зато, сука, красивый и относительно читаемый.
раскрыть ветку (3)
раскрыть ветку (1)
Очевидно, в том, чтобы знать этот самый range и додуматься его так использовать. Если ещё буду что-нибудь писать на Питоне, возьму на вооружение. Спасибо.
не писал комменты и забывал об иттерациях в циклах. хмм, а причем тут строгость языка?
Мой стандартный аргумент - в тех же плюсах, после того как поставишь {} - ты все равно внутри отступы проставляешь соответственно уровню вложенности, иначе год нечитабелен. То есть остается убрать ненужный атрибут (скобки), и вот мы логически приходим к стилю питона/руби
раскрыть ветку (33)
Аргумент вида - если после туалета все равно мыть руки, то зачем тебе туалетная бумага?
Понятно что это чисто привычка, и многие языки позволяют однострочный блок не обрамлять скобками.
Тем не менее от этого падает читабельность. Как и обычные скобки они проще для восприятия.
раскрыть ветку (32)
С чего падает читабельность, если ты, просто окинув взглядом код, понимаешь его структуру. А вот если в этом коде убрать отступы и оставить только скобки - в этом месиве надо долго копаться, чтобы понять что к чему относится.
Так что вообще не понимаю как к делу относится аналогия, и чем при наличии правильных отступов помогают скобки.
раскрыть ветку (30)
Также как и с порядком операций.
(а && в && с) // (а && в && с) // (а && в && с) - читается проще чем без скобок, хотя они избыточны, не надо глазами искать оператор "или", сразу понятно, условие проходит для трех групп и надо оказаться в одной из них.
раскрыть ветку (29)
А зачем ты сравниваешь этот вариант с обсуждаемым? Тут у тебя не было никакой группировки, и ты ее добавил для соответствия семантике.
В обсуждаемом же ты уже сделал визуальное и логическое разделение при помощи отступов.
Более подходящее сравнение - утверждать что
({а && в && с}) // ({а && в && с}) // ({а && в && с})
Это более читаемо чем то что ты предложил.
раскрыть ветку (28)
С чего бы это? Ты спросил зачем скобки, если и так понятно, я тебе написал зачем скобки и как они влияют на читабельность.
Выражение выше можно использовать без скобок, как и код с отступом. Но скобки сразу показывают как читается выражение и отсутствует необходимость разбираться что написал другой человек пару месяцев назад.
Это также удобно при написании, поскольку скобки ставятся сразу и сразу видно где кончается конструкция. Сложнее накосячить одним табом, плюс с мержами неясно как еще все будет.
раскрыть ветку (27)
С чего бы это? Ты спросил зачем скобки, если и так понятно, я тебе написал зачем скобки и как они влияют на читабельность.
Да сколько можно перевирать то.
Мы сравниваем варианты
if x == 1 {
do_something()
}
и
if x == 1:
do_something()
Насколько я понимаю, никто не оспаривает необходимость отступов. В итоге на читабельность (возможность окинуть код взлядом и быстро понять что происходит) скобки не влияют, ты будешь в первую очередь смотреть на уровни отступа. Убери уровни отступа, и любой нетривиальный код превратится в месиво, так что скобки ничего не регают для читабельности.
В воем же примере без логических операций, скобки - это скорее как отступы при ворматировании, они показывают логические блоки. Это вообще не относится к делу, так как имеет совсем другую природу.
раскрыть ветку (26)
Неа, сравниваем вот такое
if (a)
Dob
If (b)
Doc
Dod
Dog
If (f)
Dog
If (h)
Dok
Else
Dol
Else
Dov
Это мержил джун три месяца назад. Здрасьте.
раскрыть ветку (25)
Ну ты еще в пол пробела отступ сделай, ага.
Вот сравни два куска кода https://gist.github.com/Flid/d9ac7170c5b42d721e9661c148f311b... - сильно прям ухудшилась читабельность без скобок?
раскрыть ветку (24)
Там одна строчка в блоке, чего смеяться то? То что можно блок вынести в функцию не всегда вариант - как минимум придется прыгать по кучи мест, чтобы понять что и куда. А далее еще делать мутабельные переменные или плодить данные.
Опять же вопрос мержа остался. Со скобками у тебя просто не сбилдится, а с без них будешь потом ковырять что и куда.
раскрыть ветку (23)
Во-первых, "остапа понесло". При чем здесь функции и мутабельные переменные? Мы обсуждаем конкретно наличие и отстутствие {}.
Во-вторых, вот признай, ты не заметил что в одном месте не хватает открывающейся скобки, верно? Что это нам говорит? Что смотря на код, ты не смотрел на фигурные скобки, а смотрел на indentation блоков.
Так что я не понимаю, о чем здесь спорить. Скобки при правильных отступах не дают ничего полезного, но, как по мне, лишь загрязняют код.
раскрыть ветку (22)
Это говорит, что я увидел, что тот пример не имеет ничего общего с реальностью.
Во-вторых любой компилятор тебе сразу сругается если не будет скобки.
Никуда не понесло, тебе реальный пример где функция на две страницы - ты либо выносишь код в другие функции, либо ломаешь мозг, когда нет гарантии что код работает верно после мерджей.
раскрыть ветку (21)
Ну конечно людой компилятор об этом скажет. Но вопрос то не в этом. Ты же сам втирал, что фигурные скобки при правильном indentation повысят читабельность кода, верно?
А теперь выясняется, что ты на них и не смотрел даже. Как же так?
раскрыть ветку (20)
Ты читаешь что написано? Я увидел что в блоке одна строчка и закрыл. Все.
Опять же читай выше, однострочники позволяет тот же шарп, если с командой договоришься то пожалуйста.
Вопрос в разборе функции на два листа, я тебе написал структуру и то мелкую. Там любой мерж убивает полдня разбираться что и куда.
раскрыть ветку (19)
Там ни разу не одна строчка, там вложенные блоки есть. И как ты сам же говоришь, надо больше выносить в функции, так что хороший код саще так и будет выглядеть
if x:
do_this()
else:
do_that()
То что ты написал тут #comment_143819862 - пообще непонятно что, на каком языке и так далее. Хз что я должен в этом увидеть.
раскрыть ветку (16)
Там не два экрана, как это бывает на практике. Короткие условия и прочее. В чем там разбираться. Да и с телефона полэкрана скрылось.
раскрыть ветку (15)
Если функция на два экрана бывает на практике - надо менять практику.
Вполне себе реаличтичный кусок кода, только что длины строк маленькие. Назови переменные длиннее, добавь пару вызовов внешних функций - и вот самый обычный код. Но мы говорим про отступы и скобки, так что это тут не при чем.
раскрыть ветку (14)
Не надо. Скобки ведь есть. Один экран 40-45 строчек. Подготовка данных, иногда вынос условия в переменнную для читабельности, разделение условия или на несколько, линку запрос в несколько строк для читабельности. Отступы между блоками для логического деления. Логгирование.
раскрыть ветку (13)
Куча статей есть про длину функции, вот тут народ идеи кидает и подводит итоги https://softwareengineering.stackexchange.com/questions/1334...
Functions should normally be short, between 5-15 lines is my personal "rule of thumb" when coding in Java or C#.
Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.
I think the real limit is at 53 lines. With an average line size of 32.4 characters.
И это уже со всем логированием и прочим. Конечно бывают исключения, но это исключения, не надо под них оптимизировать.
раскрыть ветку (12)
Эти исключения тебе полдня убьют, за то что ты не хочешь скобок, которые ставятся сами.
Это будет основной кусок кор-логики, где разбиение на подфункции усложнит чтение, ибо придется прыгать, опять же либо мутирование, либо лишняя память.
раскрыть ветку (11)
Так и чем же тебе прям так критически помогут скобки то, ну объясни уже наконец? :) Можешь прям вот одним предложением сформулировать позицию?
Я это уже несколько раз сделал: "тебе в любом случае нужны отступы, тогда скобки теряют смысл, так как не меняют логики работы, и визуально лишь загрязняют код".
Ты вечно вокруг да около топчешься, то тебе это читабельность повышает, то что-то про длину функций, что сказать то хочешь вообще?
раскрыть ветку (10)
Тебе три раза написал про мерж. Ровно как и необходимость разбираться в нужном ли блоке стоит функция, либо ошиблись с табом.
раскрыть ветку (9)
Чем тебе с мержем помогут скобки то?! Ну приведи хоть пример какой-то.
К тому же это настолько редкая проблема, что оптимизировать под нее все в ущерб читабельности - странно.
Ровно как и необходимость разбираться в нужном ли блоке стоит функция, либо ошиблись с табом.
А если ошиблись со скобкой? Что значит ошиблись табом - как у тебя тесты прошли, как ты ревью прошел и так далее. Опять же это что-то про сказки а не реальную жизнь.
раскрыть ветку (8)
При мерже просто - есть блок условия, один дописывает строчку внизу в этот блок, другой этот блок вносит в другое новое условие. При мерже конфликта нет, а строка убежала не в тот блок.
Скобки не мешают читабельности, они как отступ идут.
раскрыть ветку (7)
Даже если вот это при конфликте правда (ни разу за 8 лет не встречался) - то это слишком редкий случай, чтобы его даже рассмастривать, ну серьезно.
И нет, в том и дело, что скобки не "как отступ идут", они идут в дополнение, добавляя как минимум один символ в строке if, и строку состоящую из "}"в конце. Это мусор, захламляющий код. Конечно, быстро тренируешься это игнорировать, но как минимум пользы от этого нет.
Так что, так и будешь утверждать, что скобки прям ваще-ваще нужны и это неоспоримо?
раскрыть ветку (6)
Значит не было больших проектов с группой разработчиков. Да или вон пишут на js люди и тогда можно говорить что не нужна строгая типизация, зачем этот мусор и так все понятно. Разве не понятно а = 1 а ="1" а = 1.0 какого это типа? Тут точно также.
А мерж можешь проверить, что там делов то.
раскрыть ветку (5)
Чуть в голос не просмеялся.
Работал в компаниях от 50 до 6000 человек, через 3 недели перехожу ведущим разработчиком в другую, там 27000.
В моей текущей команде примерно 100 человек, из них человек 30 разработчики на одном общем коде микросервиса.
Я ваще ниче не знаю о совместной работе над кодом, ага.
Наезд на JS тоже выдает в тебе плохо разбирающегося в деле профана. JS я, как заядлый бэкендер, тоже не люблю. Но я знаю что это отличный инструмент для фронтенда, когда язык сам пытается вырулить из непонятных ситуаций, что-то к чему-то привести по типу автоматически, какие-то ошибки молча проигнорировать (только залогировать).
Представь фронте-енд на условных плюсах. Вот у тебя тут при рендеринге вот этой кнопочки в углу страницы произошла ошибка, так что я тебе ваще ничего не покажу на странице, и ваще иди в жопу.
Так чебе представляешь фронт-енд?
Я тебе ответственно заявляю, если описанная у тебя проблема случается часто - у вас что-то пиздец как неправильно. У вас там 15 человек работают одновременно над одним файлом кода на 200 строк?
Так что я продолжаю настаивать на своем: форматирование отступами - это офигенная тема.
раскрыть ветку (4)
Где наезд на js? Там про типизацию речь.
Какая разница сколько там у тебя в конторе людей, если вопрос сколько в команде.
Над одним микросервисом или комплексом? 30 человек над одним чего-то это микросервис, или вы там по одной строчке пишите? И нет конфликтов? Что тогда одновременно - всего за время или одновременно? Что-то не вяжется.
раскрыть ветку (3)
Где наезд на js? Там про типизацию речь.
Ну наезд на типизацию, будто это неоспоримое зло. Я просто показываю, что ты неправ.
Над одним микросервисом или комплексом?
Над одним микросервисом. Микросервис имеет очень много логики, которая грамотно распределена по репозиторию, так что людям очень редко нужно работать над одним файлом, и небольшая синхронизация на регулярных встречах позволяет это почти полностью избежать.
Так что да, это одновременно 30 разработчиков на одном репозитории.
Напомню, что в гугле моно-репозиторий, над которым работают одновременно все разработчики. По твоей логике они должны проводить 99.99% времени в конфликтах.
раскрыть ветку (2)
Чудесный микросервис где очень много логики, что помещается одновременно 30 людей :)
Сколько же он функций выполняет в плане логики, с учетом того что часть не нуждается в доработке на текущей момент - это сколько людей на каждом функциональном куске?
раскрыть ветку (1)
Ну смотри. Сервис - сердце AI BabylonHealth. Умеет брать от пользователя набор симптомов, скармливать это в другой сервис для получени вероятностей заболеваний, выбирать какой вопрос задать следующим с кучей стратегий, плюс к этому куча фичей.
2000 коммитов, в сумме 80к строк кода.
Как-то вот живем. И самое главное - не надо рассказывать что мы что-то делаем неправильно, если это у тебя мердж-конфликты случаются регулярно :)
Кстати, однострочники без скобок обычно запрещают в команде, потому что это вносит путаницу. И если потом к этой одной строке надо добавить еще одну, то тебе придется добавить три строки на практике, что загрязняет pull request.
раскрыть ветку (1)
IT-юмор
5.6K постов52.5K подписчик
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору