Здравствуйте, Alekzander, Вы писали:
A>Вся культура современного фронта — это культура закомплексованного быдла. A>Помнишь картинку с Карлсоном: "Ты чё, пёс, я YAML-девелопер!"? A>Вот они так же комплексуют, как Карлсон. Если они не прихерачат к чему-нибудь Джаваскрипт и не напишут на нём императивный код, они чувствуют себя... кем? Верстальщиками, что ли?
P.S. И то же самое касается jQuery. Он действительно позволяет сильно упростить код, повыкидывав из него переменные с циклами, а главное — вернув разметке её роль. Потому-то у фронтеров он и пользуется презрением, как и все, кто его использует:
> Так-то jQuery наше все
А я его люблю именно за это. И даже не стесняюсь признаться.
Здравствуйте, Alekzander, Вы писали:
A>А я его люблю именно за это. И даже не стесняюсь признаться.
Непонятно чем он поможет в создании нетривиальных приложений? Ну в смысле, представь себе Office 365 например (Word, Excel, Outlook), Facebook, или Gmail.
В подобных случаях наверняка же потребуется композиция UI из блоков, которые в свою очередь состоят из блоков.
Возможность записать вызов функций в виде цепочки — ну такое, прикольно конечно но не более того IMHO.
По мне это как хвалить язык макросов в макроассемблере.
Возможно они делают работу более удобной по сравнению с ассемблером, но для написания более-менее сложных приложений это вообще не тот уровень.
Здравствуйте, bnk, Вы писали:
bnk>Непонятно чем он поможет в создании нетривиальных приложений? Ну в смысле, представь себе Office 365 например (Word, Excel, Outlook), Facebook, или Gmail.
Именно такие приложения я и пишу. Иногда с бизнес-логикой на сервере (бэк), иногда написанной на C++ на том же компьютере (десктоп).
Если платформа не поддерживает оригинальный jQuery, я пишу свой. Как я говорил ранее, для меня это не библиотека, а язык. Который даже под Хромиумом есть смысл дорабатывать напильником.
bnk>В подобных случаях наверняка же потребуется композиция UI из блоков, которые в свою очередь состоят из блоков.
И в чём проблема? Шаблонизация прекрасно делается средствами самой разметки. Можешь размножить любой блок. И блок внутри блока. И блок с блоками внутри. И даже модифицировать блок-шаблон.
А вот изолировать эти блоки, делая из них компоненты, это как раз реакционное движение.
Я рассказывал один раз, человек интересовался: у компонента в options задаются промежутки. Компонент не адаптивный, и не поддерживает разные единицы. Только число, и трактуемое только как пиксели. Он спрашивает: и как быть? Как быть: открой DOM, да посмотри, куда вписать rem'ы. А если работать с компонентами лишь через их интерфейс (включая options), только сам себя ограничиваешь, вот и всё. И зачем это делать?
bnk>По мне это как хвалить язык макросов в макроассемблере. bnk>Возможно они делают работу более удобной по сравнению с ассемблером, но для написания более-менее сложных приложений это вообще не тот уровень.
Я считаю, что правильное сравнение — как LINQ в C#. Только вместо коллекций — DOM.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Такая форма мне кажется весьма извращенной, но как эту извращенность если не ликвидировать, то хотя бы просто уменьшить?
Я пишу похоже на вариант Marty, только без излишнего выравнивания выражений — каждый следующий nesting level отличается на один tabstep:
Здравствуйте, netch80, Вы писали: N>и такого вокруг мегатоннами. N>Кто-то же заставляет так форматировать?
Ребята, которые в 16 веке потратили время и силы на выработку принципов вёрстки, уважительной к читателю. Если что, Кнутовский алгоритм из TeX растёт корнями как раз оттуда.
Человек читает не по одной букве/пикселу — есть определённая ширина, в пределах которой можно воспринять текст без "горизонтального скроллинга".
Делаем текст шире — и человеку приходится рисовать глазами "змейку" слева-направо-обратно-ой, я потерял начало строки. Это катастрофически утомляет зрение.
А вот чтение "узкого" текста позволяет плавно вести взгляд вертикально вниз — а потом прыгать в начало следующей колонки. Вот эти прыжки а) легче, потому что ширина колонок относительно велика, и навестись на начало следующего чанка можно безошибочно и б) нужны два раза на страницу, а не 50-60.
То же самое в газетах — никто не верстает тела газетных статей во всю ширину листа. И не потому, что "наборная машина не позволяет".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Нomunculus, Вы писали:
Н>Тебе так норм? Н>
Н>for (int i =0; i < 10; i++) { int tempVar = 0; callMyFunction(i); if (b < 10) i—-; else { tempVar += 10 } }
Н>
Это ты на пустом месте раздуваешь — специально так делать не надо. Есть многословный код для работы с библиотеками, где получаются длинные вызовы функций/методов и не хочется делать их многострочными. Например:
auto builder = YoloONNXUniquePtr<nvinfer1::IBuilder>(nvinfer1::createInferBuilder(sample::gLogger.getTRTLogger()));
const auto explicitBatch = 1U << static_cast<uint32_t>(nvinfer1::NetworkDefinitionCreationFlag::kEXPLICIT_BATCH);
auto network = YoloONNXUniquePtr<nvinfer1::INetworkDefinition>(builder->createNetworkV2(explicitBatch));
auto config = YoloONNXUniquePtr<nvinfer1::IBuilderConfig>(builder->createBuilderConfig());
auto parser = YoloONNXUniquePtr<nvonnxparser::IParser>(nvonnxparser::createParser(*network
auto constructed = ConstructNetwork(builder, network, config, parser);
m_inputDims = network->getInput(0)->getDimensions();
assert(m_inputDims.nbDims == 4);
m_buffers = std::make_unique<samplesCommon::BufferManager>(m_engine, 0/*m_params.batchSize*/);
m_context = YoloONNXUniquePtr<nvinfer1::IExecutionContext>(m_engine->createExecutionContext());
Аналогично логирование и т.д. Тот код, который не содержит в себе особо сложной логики, не планируется к частому прочтению или особому пониманию вполне может быть длинным.
Здравствуйте, Sinclair, Вы писали: N>>и такого вокруг мегатоннами. N>>Кто-то же заставляет так форматировать? S>Ребята, которые в 16 веке потратили время и силы на выработку принципов вёрстки, уважительной к читателю. Если что, Кнутовский алгоритм из TeX растёт корнями как раз оттуда. S>Человек читает не по одной букве/пикселу — есть определённая ширина, в пределах которой можно воспринять текст без "горизонтального скроллинга". S>Делаем текст шире — и человеку приходится рисовать глазами "змейку" слева-направо-обратно-ой, я потерял начало строки. Это катастрофически утомляет зрение. S>А вот чтение "узкого" текста позволяет плавно вести взгляд вертикально вниз — а потом прыгать в начало следующей колонки. Вот эти прыжки а) легче, потому что ширина колонок относительно велика, и навестись на начало следующего чанка можно безошибочно и б) нужны два раза на страницу, а не 50-60.
Увы, это абстрактное кэпство не в тему.
Вот берём другие примеры документации:
Intel
ITU
ISO
читается легче.
Среди мира книжной печати (а документация в PDF относится к этому миру) IBM чуть ли не единственные, кто использует двухколоночную вёрстку. Почему?
Я думаю, как раз фактор прыжков между двумя колонками влияет больше в минус, чем ширина в разумных пределах.
Могу примеров надёргать и из книг, в pdf/djvu/epub их достаточно. Нетехнических у меня вроде нет, но всякие "C# and .NET" или "Java in practice" показывают тоже один столбик и ширины 80-110 на видимую строку. S>То же самое в газетах — никто не верстает тела газетных статей во всю ширину листа. И не потому, что "наборная машина не позволяет".
Тут обсуждали недавно про оптимум ширины строки в символах.
В печатных книгах, я померял, типовые ориентиры пляшут вокруг цифр в 50-70 символов (пропорциональные шрифты не дают остановится на точной цифре). Но их, кроме энциклопедий, словарей и т.п., не печатают в две колонки! Думаю, если бы их печатали в две колонки, их бы не читали.
Итого тема не раскрыта. Хочу увидеть нормально обоснованный ответ, а не "это закон жизни, потому что тайна веков"™.
ЕМ>А добавить const к существующей переменной, насколько я знаю, не позволяет ни один язык.
Добавить нет, но и вычислять одним выражением уже нет необходимости. Тем более, что не всё можно запихнуть в тернарку (например, циклы).
Immediately invoked lambda function
Мне лично не нравится в таком подходе наличие в коде return, за который цепляется глаз, и который может вызвать ложное ощущение возврата из охватывающей функции.
Но проблему сложной инициализации оно решает.
И точку останова, в отличие от тернарки, можно поставить на конкретную ветку.
Здравствуйте, bnk, Вы писали:
bnk>Решается 49" монитором (сейчас цены уже нормальные, конкурентов стало много), три окна side-by-side по 150 колонок входят запросто.
И тут мы переходим на следующую итерацию: раз мониторы у нас широченные, давайте лепить строки по 300 символов, чего месту на экране пропадать.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну кстати, да. Текст на естественном языке (не на языке программирования) трудно читать, если он шириной под 80 символов или больше.
Я рядом приводил примеры: 1, 2, 3 — хорошо читается, нет проблем (при нормальном или правильно откорректированном зрении). Типовая длина там 100-130 символов.
Pzz> Если немного вспомнить историю, в добрые старые перфокарточные времена максимальная ширина текста была 72 символа, и еще 8 символов отводилось под порядковый номер перфокарты, по которым случайно рассыпанную колоду можно было автоматически отсортировать с помощью сортировальной машины (правда на практике эта возможность редко использовалась). Pzz>Полагаю, эти 72 символа взялись не с потолка, а с практики книгопечатанья или написания писем и основаны на накопленном опыте, а не случайны.
Ты, наверно, не помнишь пишущие машинки механических и ранне-электрических времён.
У большинства была узкая каретка и шкала разметки до 80 символов, у меня была такая (переделанная ещё трофейная, по слухам, марки производителя не осталось). Но в учреждениях (по крайней мере в Киеве) были типовые механические или электрические "Ятрань", у них можно было спокойно и до 120 — влезало, если укладывать бумагу в альбомной (landscape) ориентации, так печатались, например, широкие таблицы.
80 это ширина, сколько влезало при стандартном шрифте машинки и нормальных полях в лист A4 (или Letter, для США) в портретной ориентации.
При этом ставились (а могли и неподвижно стоять) два бегунка на планке разметки: один давал звяк при переходе через него, и его ставили на позицию 71 или 72, чтобы после этого сразу написать перенос слова на положенной границе (и опытная машинистка реагировала на звук, без необходимости контроля глазами). Второй, ставили обычно на 80, не давал физически двигаться дальше. У моей машинки оба двигались, после позиции 80 разметка не была нанесена, но физический предел каретки наступал где-то на 98, уже плохо помню.
80 символов перфокарты шло как раз из этого стандарта. А дальше, почему именно 8 (а не 5 или 10) отвели на хвостовую часть, где можно было писать номер карты или короткую метку — можно попытаться уточнить (на каком-нибудь retrocomputing.SE, там любят такие темы и есть знатоки), но уже не настолько существенно.
(As an aside, this is why early FORTRAN versions imposed a 72-character limit on source lines: the first FORTRAN compiler ran on the 701's successor, the IBM 704, which could only read 72 columns of a card — see p. 39 of the 704 Manual of Operation (31 MB PDF). As others have noted, the 8 ignored columns were often used to encode a sequence number for each card, which could be a lifesaver for the unfortunate programmer or operator who dropped a card deck on the floor.)
(Отсюда — но это не полный ответ для данного вопроса.)
Заметим, что было несколько ширин перфокарт. ЕС-6012, читалка перфокарт с которой я работал, имела режимы на 45 и 80 колонок. Я вживую 45-колоночные никогда не видел.
Pzz>Сейчас про этот резерв в 8 символов как-то забыли, и "общепринатая" ширина увеличилась до 80-и символов, что вообще-то великовато для восприятия. А уж превышение ее восприятию совсем уж не идет на пользу.
Насколько я вижу обсуждения и решения вокруг, это давно не так. Большинство предпочитает разрешать строки до 100 или 120 символов. На некоторых моих работах такие изменения к внутреннему стандарту стиля были приняты на моих глазах — и я не нашёл аргументов против.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А любой ли компилятор сумеет это свернуть в код без формирования функции и ее вызова?
Наверняка не любой, и не при любых настройках оптимизаци.
Мне ответ на этот вопрос неинтересен. А интересен ответ ответ на "будут ли компиляторы, которыми я пользуюсь для сборки релиза генерировать код не хуже, чем без IIL".
И да, мой ответ был бы скорее всего да (99%) для данного кода, но если важно, то нужно проверить.
"Любой компилятор" может в принципе не поддерживать C++11 и выше, mandatory RVO, разворот циклов и множество других вещей, влияющих на скорость выполнения. Ориентироваться на "любой компилятор" не вижу никакого смысла.
Задачи написания максимально эффективного с точки зрения выполнения и максимально читабельного (что вообще субъективно) кода вообще конфликтуют зачастую.
А вот встречный вопрос:
предположим, что TypeWithLongName нетривиален и его копия/перемещение дороги.
А любой ли компилятор сможет в случае тернарного выражения выкинуть промежуточный временный объект-результат собственно тернарного выражения и сразу создавать VarWithLongName без копии/перемещения?
Хинт — нет, не любой и не с любыми настройками оптимизации (msvc /O0 точно не выкинет, возможно и с оптимизацией тоже) и тут стоимость копии может превысить расходы на вызов лямбды.
А версия с лямбдой — да, т.к. RVO.
Кроме того, у тебя там `?:`, т.е. бранч, стоимость миспредикшена которого может превысить стоимость вызова.
В случае с if, я могу добавить `[likely]]` и потенциально улучшить код, для тернарного оператора такой опции нет.
Короче, как всегда, написание оптимального кода без профилирования — дело неблагодарное.
Конкретно данный пример я бы написал с лямбдой, из-за RVO.
Здравствуйте, Нomunculus, Вы писали:
S>>Но там где { — лучше с новой строки. Так же ; — кроме как внутри for — тоже с новой строки. Н>Ну и о чем тогда топик?
О всё более длинных идентификаторах, скорее всего.
Здравствуйте, Pzz, Вы писали:
Pzz>Я предпочитаю укладываться в 80. И меня бесит код, который не укладывается. Pzz>И да, неспособность автора уложиться в 80 часто коррелирует с тем, что автор плохо понимает, что пишет.
Простая формула на современных идентификаторах в 16-20 символов не влезет, да еще плюс отступы...
/* printf-tac-toe: tic-tac-toe in a single call to printf
* Copyright (C) 2020 Nicholas Carlini.
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, version 3.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/#include <stdio.h>
#define N(a) "%"#a"$hhn"#define O(a,b) "%10$"#a"d"N(b)
#define U "%10$.*37$d"#define G(a) "%"#a"$s"#define H(a,b) G(a)G(b)
#define T(a) a a
#define s(a) T(a)T(a)
#define A(a) s(a)T(a)a
#define n(a) A(a)a
#define D(a) n(a)A(a)
#define C(a) D(a)a
#define R C(C(N(12)G(12)))
#define o(a,b,c) C(H(a,a))D(G(a))C(H(b,b)G(b))n(G(b))O(32,c)R
#define SS O(78,55)R "\n\033[2J\n%26$s";
#define E(a,b,c,d) H(a,b)G(c)O(253,11)R G(11)O(255,11)R H(11,d)N(d)O(253,35)R
#define S(a,b) O(254,11)H(a,b)N(68)R G(68)O(255,68)N(12)H(12,68)G(67)N(67)
char* fmt = O(10,39)N(40)N(41)N(42)N(43)N(66)N(69)N(24)O(22,65)O(5,70)O(8,44)N(
45)N(46)N (47)N(48)N( 49)N( 50)N( 51)N(52)N(53 )O( 28,
54)O(5, 55) O(2, 56)O(3,57)O( 4,58 )O(13, 73)O(4,
71 )N( 72)O (20,59 )N(60)N(61)N( 62)N (63)N (64)R R
E(1,2, 3,13 )E(4, 5,6,13)E(7,8,9 ,13)E(1,4 ,7,13)E
(2,5,8, 13)E( 3,6,9,13)E(1,5, 9,13)E(3 ,5,7,13
)E(14,15, 16,23) E(17,18,19,23)E( 20, 21, 22,23)E
(14,17,20,23)E(15, 18,21,23)E(16,19, 22 ,23)E( 14, 18,
22,23)E(16,18,20, 23)R U O(255 ,38)R G ( 38)O( 255,36)
R H(13,23)O(255, 11)R H(11,36) O(254 ,36) R G( 36 ) O(
255,36)R S(1,14 )S(2,15)S(3, 16)S(4, 17 )S (5, 18)S(6,
19)S(7,20)S(8, 21)S(9 ,22)H(13,23 )H(36, 67 )N(11)R
G(11)""O(255, 25 )R s(C(G(11) ))n (G( 11) )G(
11)N(54)R C( "aa") s(A( G(25)))T (G(25))N (69)R o
(14,1,26)o( 15, 2, 27)o (16,3,28 )o( 17,4, 29)o(18
,5,30)o(19 ,6,31)o( 20,7,32)o (21,8,33)o (22 ,9,
34)n(C(U) )N( 68)R H( 36,13)G(23) N(11)R C(D( G(11)))
D(G(11))G(68)N(68)R G(68)O(49,35)R H(13,23)G(67)N(11)R C(H(11,11)G(
11))A(G(11))C(H(36,36)G(36))s(G(36))O(32,58)R C(D(G(36)))A(G(36))SS
#define arg d+6,d+8,d+10,d+12,d+14,d+16,d+18,d+20,d+22,0,d+46,d+52,d+48,d+24,d\
+26,d+28,d+30,d+32,d+34,d+36,d+38,d+40,d+50,(scanf(d+126,d+4),d+(6\
-2)+18*(1-d[2]%2)+d[4]*2),d,d+66,d+68,d+70, d+78,d+80,d+82,d+90,d+\
92,d+94,d+97,d+54,d[2],d+2,d+71,d+77,d+83,d+89,d+95,d+72,d+73,d+74\
,d+75,d+76,d+84,d+85,d+86,d+87,d+88,d+100,d+101,d+96,d+102,d+99,d+\
67,d+69,d+79,d+81,d+91,d+93,d+98,d+103,d+58,d+60,d+98,d+126,d+127,\
d+128,d+129
char d[538] = {1,0,10,0,10};
int main() {
while(*d) printf(fmt, arg);
}
Здравствуйте, Shmj, Вы писали:
S>Вот, по умолчанию в той же Idea — около 75 символов. По сути это газетная строка или близко к ней.
S>А ведь можно было сделать длинным? Ну хотя бы 150-200 символов. И читать код как книгу. Тем более мониторы то расширяются.
Здравствуйте, Shmj, Вы писали:
S>Вот, по умолчанию в той же Idea — около 75 символов. По сути это газетная строка или близко к ней.
S>А ведь можно было сделать длинным? Ну хотя бы 150-200 символов. И читать код как книгу. Тем более мониторы то расширяются.
S>Не пробовали? Что лучше? Сколько символов ставите?
У меня максимальная длинна строки 120-140 символов, это для java/C# т.к. в ынтерпрайзе бывают достаточно длинные имена.
Чего стараюсь избегать
1) вложенных вызовов, код вида f(g(some(x)), other var ) будет реализован через сохранение переменных, для удобства отладки
Не знаю откуда пошла такая мода в шарпах, котлине и джаве, это при вызове, каждую переменную писать на отдельной строке, возможно в Си/С++ это оправдано, я сам на них не писал прод код
Но в java/C#/kotlin для понимания контекста функции сидишь и скролишь как идиот и ладно бы только в сигнатурах такое было, так нет, с именованными параметрами и на каждой строке
на любой чих делают перенос, такое ощущение, что это какие-то зомби из прошлого, у которых монитор 640 на 480 точек.
для меня перевод строки это либо перенос длинной строки, в котлине это вызов с именованными параметрами
типа myFunc(var1 = val1, var2 = someVal2... ) и так далее, что по сути удлиняет строку в 2 раза, но позволяет не путаться между параметрами с одинаковым типом, особо распространено среди ресто жсоновских помоев.
когда все айдишники приходят строкой или числом и их тип нельзя обособить.
Но в среднем код укладывается в 60-90 символов.
Еще видел подобное у фронт разработчиков на реакте
когда вместо
<Component prop1 = "prp1" prop2 = "prp2" />
Пишут
<Component
prop1 = "prp1"
prop2 = "prp2" />
Когда уже IDE для таких разработчиков встроят справа рекламу, все равно место пропадает, да и лет через 20 писать код уже будут все, по этому пора бы сделать ынтерпрайз IDE с рекламой, а не хочешь рекламу — покупай лицуху.
Pzz>Полагаю, эти 72 символа взялись не с потолка, а с практики книгопечатанья или написания писем и основаны на накопленном опыте, а не случайны.
"Но он же не ветеринар!" (С) анекдот.
Да, книжная строка, в которой 72 символа, и где-то 60-64 непустых в среднем, вполне комфортны. Однако агрессивные стадА любителей под одну гребенку всегда требуют, чтобы гребенка была их. А значит, для "{" и "}" требуется отдельная строчка, и написать if (a > 1) x++ следует не в одну, а в 3 строки (или 4, если, как нравится многим, перед if требуется оставить пустую строку):
if (a > 1)
{
x++;
}
А коли к тому еще и else добавить, то даже самый простой код быстро начинает требовать вертикального скроллинга. Вместо того, чтобы уместиться в пару строк.
Как человек, читающий очень много кода — нет ничего хуже необходимости вертикального скроллинга. Поэтому идиотизм из серии "в этой функции 60 строк, слишком длинная, разделим на 3 по 20" есть идиотизм, и ничего более. Три функции по 20 строк, между которыми передаются все переменные, читать сложнее, чем одну 60-строчную. Выделять отдельные сущности нужно тогда и только тогда, когда этим можно уменьшить размер контекста.
S>Вот пример кода другого разработчика который я недавно переформатировал. Какой из вариантов готов к дальнейшему расширению?
Первоначальный вариант лучше: объем контекста одинаков, функции исполняются строго последовательно, читать одну функцию проще, чем скакать по нескольким.
К тому же ни одна из выделенных функций сама по себе не имеет применения. То есть выделение функции просто ради выделения. Зачем?
Выделять надо там, где или становится доступным повторное использование, или можно уменьшить размер контекста (путем передачи, скажем, 3 параметров вместо 12). Лучше и то, и другое сразу. Но если в конечном итоге все равно нужно разбираться, то проще разобраться в одной, чем в 5 функциях.