не всегда есть IDE под рукой, чаще Sublime какой-нибудь. Да и если я открыл в IDE, то она знает мой стиль, но не знает стиля, которым написан открываемый код. Обратно вернуть к стилю не получится.
Для своих проектов стиль почти всегда унифицируется — это правило перед началом работы.
Это какое-то написание кода в стиле «итальянской забастовки». Можно извратить всё что угодно таким подходом. В вашем случае в code-style-ref будет прописано, что после определения функции пустую строчку вставлять не надо. И как в примере ниже, будет прописано, что комментарий пишется над функцией, а не между её объявлением и телом. Везде надо находить золотую середину.
// function foo
void foo()
{
}
void boo()
// function boo
{
}
Я не спорю, а выразил своё субъективное мнение и обосновал почему. Если для вас всё иначе — можете выразить почему именно так. Ну, ещё можете минусов расставить. В любом случае, если есть реакция, значит я по-своему прав.
Только о форматировании. Организация кода — отдельная тема. Но сколько бы любая IDE не делала код красивым, такой код, например, нельзя будет закомитить (имею в виду чужой код, если пришлось исправить в нём ошибку по таске), такой код ужасно читать в mc.
Тут можно было бы спорить, что скобка слишком мала, чтобы восприниматься выражением. Но читабельность — это прежде всего. Объясню почему: если я могу бегло читать код, не останавливаясь и не разбирая где же это начало блока и где конец, то мне не прийдётся листать постоянно вверх-вниз и достаточно одного прохода по коду, чтобы уловить суть не вникая при этом в детали реализации и не ища глазами в строка скобку начала блока — это тормозит и сбивает запоминание. В таком случае неважно насколько вертикально растянут код, когда в голове последовательно сложена картинка.
За свою практику я вывел одно жёсткое правило: когда код написан разборчиво (а именно: с пробелами вокруг операторов, переносом скобок, пробелами между атомарными блоками кода и без сокращений в именах переменных), то сделать такой код говно-кодом тяжело, в то же время в таком коде можно легко найти даже неправильную логику лихого школьника. Приучайте писать код читабельным и красивым.
Экономя строку на переносе скобки — вы тратите мои драгоценные минуты на поиск этой скобки по коду, когда она не подсвечивается или находится за пределами половины одного экрана.
В приведённом выше решении расположить табы и вкладки в отдельных контейнерах как раз не составит труда. Label можно вынести куда угодно, а скрытый radio и контейнер останутся на одном уровне.
Ещё один бесящий меня момент — помнить алгоритмы, которые ты никогда не пишешь в своей жизни, а используешь готовые. Меня сходу можно отсеять в таких компаниях. И не страшно за 10-летний опыт разработок, умение оптимизировать/профилировать сложные запросы, главное — это решение тестового задания, предназначенного для только получивших диплом выпускников матвузов.
Интересно, там где ON CONFLICT DO UPDATE, так же как в mysql будет увеличивать auto_increment (sequence) счётчик? Если да, то такая функциональность мало полезна.
Для своих проектов стиль почти всегда унифицируется — это правило перед началом работы.
П.С. Поворот поезда определённо нравится. Чего нехватает во всех Tycoon-ах.
а величина кривизны возле точки настраивается в зависимости от расстояния (длин векторов) между точками.