Comments 66
Первый совет (про пустые строки в начале и конце каждого уровня вложенности) я бы отнёс скорее к вредным советам или по крайней мере к попытке навязать свой экзотический Code Style (приемлемо, если вся команда его использует, но если нет – я бы крайне не рекомендовал внедрять). Не надо так.
Специально для вас в начале статьи:
В процессе внедрения предложенных мной концепций, вы с высокой вероятностью можете столкнуться с тем, что код будет выглядеть непривычно для вас, и внутренняя консервативность будет подталкивать к тому, чтобы писать код "по старому".
Однако, можете мне поверить, если вы сможете позволить себе пройти через адаптацию, код не соответствующий данным концепциям оформления будет вызывать у вас отвращение, т.к. будет напоминать слипшуюся кашу трудную для восприятия. К тому же в статье я не просто описываю приёмы, но и рассказываю, для чего это нужно.
Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉
P.S.: После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте. На первый взгляд оформленный таким образом код выглядит дико, и я тоже через это проходил.
Ну конечно же программисты, разрабатывающие стэнфордский стандарт оформления кода и Ричард Столлман, создавший стандарт кодирования GNU, были глупее вас и не догадались добавить пустые строчки.
После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте.
То, что код без пустых строк внутри уровней вложенности, каша - это ваше субъективное мнение.
Вам так удобнее? Видимо, да. Будет ли другим так удобнее? Совершенно не обязательно.
Именно об этом я и написал в статье:
Всё вышеописанное является моим личным субъективным мнением и видением ситуации. Оно не обязательно должно совпадать с вашим мнением и видением.
Как написал и то, что
После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте.
После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте.
Вы, мне кажется, не очень понимаете, что я вам хочу сказать.
То, что писать кашу из когда - даунгрейд, разумному программисту понимать уже не надо, он это уже понял достаточно давно. Вопрос в том, какой подход не будет производить кашу.
Вы вот утверждаете, что ваш. А я считаю, что мне ваш подход не подойдет, и не вижу смысла это проверять. Догадаетесь, почему?
Что гадать, я ответ на этот вопрос ещё в начале статьи написал:
В процессе внедрения предложенных мной концепций, вы с высокой вероятностью можете столкнуться с тем, что код будет выглядеть непривычно для вас, и внутренняя консервативность будет подталкивать к тому, чтобы писать код "по старому".
И в комментариях выше дополнил:
Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉
Что гадать, я ответ на этот вопрос ещё в начале статьи написал:
...и это неправильный ответ. Попробуете еще раз?
Всегда проще отказаться, чем попробовать.
Ну да, проще отказаться от изменений в уже работающей системе, чем менять, если преимущества не очевидны.
Где сопротивление, там точка роста
Это совершенно не обязательно.
Для вас отказ от этих пустых строк есть трудность? Если да, то это точка роста и отказаться от нее, конечно, проще, чем пробовать. Надо просто дольше пробовать.
я-то могу сравнить оба подхода, т.к. писал и без пустых строк, и с пустыми строками. и я выбираю второй вариант, для меня после моего практического опыта, его преимущества очевидны. как и для коллег, которые прошли через сопротивление и адаптацию.
а кто не может себе позволить попробовать писать с пустыми строками - не могут и сравнивать, из за банального сопротивления непривычному
Особенно радует закрывающая фигурная скобка.
Мало того, что она почти всегда одна в строке.
Так ещё и отделяется пустыми строками с двух сторон.
Мля... Ну есть же Airbnb Style Guide. Миллионы к нему привыкли и давно пользуются. И тут вы такой красивый, здравствуйте...
Есть множество подходов, причём некоторые из них не взаимоисключают друг друга. Я делюсь подходом который показал свою эффективность как лично для меня, так и коллеги позволившие себе попробовать такой подход, неоднократно отмечали его преимущества. К тому же, если что-то уже есть, и без разницы от кого, это не значит, что теперь лучше уже не может быть, и не значит, что не стоит стремиться к лучшему.
Опять же, это моё мнение, и я его никому не навязываю. Кто-то прочтёт и скажет "фи", пропустит "мимо ушей" так сказать. А кто-то попробует, и получит пользу, и плюсы данного подхода станут для него очевидны.
не секу во фронтах, там что, линтеров нет? решили поднять статью на холиваре табы против пробелов?
Это
как-то
чересчур.
Та тут сборник плохих советов сплошной. 2 пробела (4 плохо 2 хорошо, все иде ошибаются, раз ставят по умолчанию 1й варик?), особые пустые строки я ничего не понял там, также вот это клеим строки со сроу, или любим клеить фигурные (не везде любят, не везде так). Это ж сколько свободного времени, очень завидую. Зато я безработный сейчас, а чел наверняка с работой. Наверно круто работал, не то, что мы с вами. П***ц.
Тернарный хорош в случаях где константная объявляется, или где в одну сторону, а вот эти переносы после двоеточия... Ну такое
Вообще все остальное согласен. Про дублирование, и про то, что не должно слипаться и магчисла
Использовать тернарный оператор что бы не писать if/else в несколько строк;
Размазывать написание на несколько срок для улучшения читаемости.
У меня одного ощущение неправильности в этом подходе?
Я вообще без работы никогда не сижу, и даже сам в том числе предоставляю людям работу. Людям, готовым открываться положительным изменением, расти через сопротивление, и позволить себе попробовать вопреки своим устоявшимся привычкам, новый подход.
Обратите внимание - попробовать. Не принять как истину по вере на слово, а именно попробовать. Да, не критиковать, не ставить себе барьеры, а именно - попробовать.
И как ни удивительно - ещё никто из тех, кто написал проект с таким подходом, назад, к старому подходу уже не вернулся. При этом каждый (и я в том числе) проходил через сопротивление и отторжение этих пустых строк.
Я уже не раз писал здесь в комментах - "Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉". Но право каждого - сделать свой личный выбор. Этот выбор не обязательно "попробовать". Можно сразу уйти в отрицание, критику, минусить, и продолжить жить и работать по старому. Ну критикуйте, минусите, пока ваши коллеги учатся по этому гайду, и лично со мной зарабатывают деньги 😉
это реальное фото или просто случайный сток из интернета?
потому как если реальное фото, то я бы поостерегся слушать советы от человека, который почти закончил трансформацию в охранника (4+ монитора))))
ну а ты как думаешь?))))
если ты считаешь, что много мониторов может быть только у охранника, можешь глянуть следующий видос, в котором кстати в том числе раскрывается тема мониторов
судя по образу в видосе выше я примерно представляю, как (точнее сказать под чем) придумался такой беспощадный код-стайл...
но вряд-ли представляете как достичь результатов, которые я достиг даже не сейчас, а ещё года 4 назад 😀
очень даже представляю, все очень просто - надо работать и развиваться, всякие пробелы в коде здесь вообще не причем, они скорее отвлекают
и в отличие от вашего - это не только и не столько мое мнение, это элементарный факт, а эти пробелы больше попахивают подростковым бунтарством - сделать не как все - но этого мало, вот если придумать что-нибудь не как у всех, и чтобы при этом это было удобно хотя бы какой-то значимой части сообщества - вот это результат, а пробелы и пустые строчки в коде - пустозвонство. По простой причине - если пользуешься, например, не vs code - при простейшем копировании нескольких строчек кода - они вставляются с другим форматированием, и надо опять форматировать, то уже форматировал - это между прочим очень удобно и невероятно ускоряет разработку! И это только первая причина, а их Вам озвучили уже с десяток (а может и не один)
Все работают и развиваются, просто по разному. Поэтому я и привожу наглядный пример с тем, что видно мгновенно - как выглядит рабочее место. Вы конечно можете спорить, считая, что можно работать за одним монитором всю жизнь, или за ноутбуком. С яркой лампой накаливания над головой. Да, можно. Если хотите достичь среднестатистических результатов, а не впечатляющих для самого себя. Личный выбор каждого. И про порядок в коде - я уже в статье всё написал. Если после прочтения не стало понятно, и захотелось спорить, доказывать свою точку зрения сравнивая подход с которым есть опыт с подходом в котором нет опыта - тут я ничем не могу помочь. Спорьте. Действуйте только как раньше. Вы абсолютно правы во всём. Оставайтесь правыми дальше.
с вами никто не спорит, спорить можно только с человеком который видит хотя бы чуточку шире своего мнения, или хотя бы хочет видеть чуточку шире, а вам просто пишут факты, не более
видит шире своего мнения лишь тот, кто пробует смотреть с разных точек зрения, а не с единственной 😃
я писал код и другими способами, а вы не писали код предложенным мной способом
и кто из нас видит шире своего мнения, сравнивая эти два подхода? (вопрос риторический 🤓)
Не обязательно быть поваром, чтобы оценить качество блюд.
но при этом обязательно быть поваром (обладать навыками приготовления пищи), чтобы рассуждать о способах приготовления пищи.
и действительно сравнивать способы "приготовления пищи" и делать какие-либо выводы о них может лишь повар, практиковавший эти способы. иначе все эти "выводы и сравнения" будут лишь пустозвонством.
с чего вы взяли что я не писал код вашим методом? думаю на этом смысла дальше спорить нет смысла )) потому что вы думаете что вы умнее всех и все знаете, и именно поэтому ваш метод никчемное выпендрёжничество и не более...
в ваших идеях разумное зерно, но итоговый результат ужасен, код ничитабелен от слова совсем, особенно когда компонента разрастается - эти пустые строки - это просто боль, пробелы около знака = при передаче пропсов - это тихий ужас
а как вы работаете, поделитесь, господа критики?
Нормально работаем. Еще ни разу за двадцать лет никто не предъявлял претензий к code style.
я тут скорее про то, как выглядит ваше рабочее место, после 20 лет опыта в разработке
Это противоречит треду (в этом месте еще никто не упоминал про рабочее место), но не суть.
Рабочее место как рабочее место - клавиатура, мышь, монитор.
Вот стол и кресло нормальные подобрать - это реально проблема, которую я до сих пор не могу решить. И если с креслом она, кажется, все-таки решается "просто залейте деньгами", то бишь купите какой-нибудь аэрон, то со столом я что-то окончательно перестал видеть варианты кроме "сделайте на заказ".
каким образом эта статья повысит уровень разработчика? или по вашему мнению чем больше пробелов - тем выше скилл?
Есть исследование, что от 2 до 4 - эквивалентно для восприятия.
Я считаю, что в разных языках по разному воспринимаются табы. Гдето 2 достаточно, гдето лучше 4. Это зависит от уровня вложенности типичных блоков. Где можно писать маленькие фунции, там 2 за глаза. Где в основном большие портянки (какие нибудь хп на tsql), то лучшее добавить.
Обязательно настройте, чтобы TAB был равен двум пробелам, а не четырём - иначе код будет слишком расплющен в ширину при большом количестве вложенных друг в друга элементов.
А может просто не делать миллион уровней вложенности?)))
Ни в коем случае не дублируйте код
Если ваш код похож на 99%, то это не всегда значит, что его надо объединять
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Объясню для чего это нужно. Часто приходится работать над несколькими файлами одновременно, т.к. их логика связана друг с другом. Если у вас на дисплее открыт только один файл с кодом - значит лишь то, что вы не открыли для себя возможность открывать одновременно 2, 3 и более файлов с кодом одновременно, разделяя рабочее пространство редактора кода, экономя время и свой фокус внимания, вместо того, чтобы переключаться между вкладками или окнами.
Когда одновременно открыто несколько файлов, чем более сжатый код, тем больше его помещается в не таком уж и широком окне области одного файла. А код желательно видеть полностью (по ширине), чтобы опять же не тратить время на листание влево-вправо.
Насколько мы можем сжать код? Один пробел - это один символ. Пробелы нужны, на одном пробеле не построить табуляцию, т.к. будет путаница. Получается минимальное расстояние - два пробела. Его мы и используем. Можно хоть 10 поставить, но всегда нужно понимать - ради чего.
ну как бэ можно делать строчки не более 120 символов в длину и все будет нормально помещаться на половинках экрана)
я табами вообще не пользуюсь, меня от них почему-то воротит, предпочитаю 4 пробела
я насмотрелся проектов, где отступ был 2 пробела - это ужас; читать такое невозможно, потому что это сплошная стена текста
по поводу 3+ уровней вложенности - это настолько редкое явление, что я не помню когда на проекте видел такое последний раз; правда я бэкендер, на фронте похоже совсем беда со вложенностью из-за хтмла
В разных языках могут быть разные стили отступов. Я бы пользовался тем, что принято в большинстве проектов конкретного языка. Кажется, в JS любят 4, и тогда смысла изобретать свой стиль никакого.
Во Flutter вёрстка - вызов функций (на языке Dart, с синтаксисом, напоминающим C++), аргументы которых - другие функции. И там может быть сколько угодно вложенностей: одна функция задаёт паддинги, её аргумент child задаёт содержимое, аргумент функции в child задаёт рамку для этого содержимого, аргумент функции рамки задаёт её цвет (тоже через функцию) и т. д. Императивный подход синтаксисом декларативного языка.
На 21:9 мониторе удобнее все
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Ну вот смотрю я на 2 и 4 - для меня одинаково, для когото лучше 4, для кого-то 2. Вы же пытаетесь доказать что только вы правы.
Есть куча книг на тему стайлов, написанных умными людьми. Просто их прочитайте и не придумывайте велосипеды
А смысл, что вы всё это расписали словами и не выложили свой файл конфига eslint?
В команде или организации должен быть принят единый шаблон стиля оформления кода, особенно если используется несколько ide
При ревью отклонение от стиля должно преследоваться, дабы отдельные личности с индивидуальной тягой к прекрасному не привносили бардак
Код должен автоформатироваться при написании
В функции должно быть 3-5 переменных
Размер функции не более 25 строк, или один экран
А уж сколько пробелов в табуляции или где стоит открывающая скобка - не таа важно, имхо
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Напишите файл со сложной вёрсткой с кучей вложенностей и сделайте там табы в 8 символов.
Затем сделайте дубликат файла, и там сделайте табы в 2 символа
Сравните, сделайте выводы
Или вы больше верите другим, чем собственному восприятию?
Или вы больше верите другим, чем собственному восприятию?
Спросите это у тех, кто написал 30 млн. строк кода ядра Linux :)
Я мне сравнивать незачем, я за 30 лет программирования успел сравнить всё, что только можно.
собственному восприятию
Собственное восприятие весьма гибкое. Сегодня вам нравится 2 пробела и пустая строка, а через год будете от этого кодстайла плеваться. Проверено на практике.
На самом деле половина возражений против Вашей статьи пропало бы, если бы Вы не написали в начале
данный подход может быть применён к любому из языков программирования, и базирующихся на них фреймворках.
а на компоненты сложную верстку слабо разбить?
Мне кажется об оформлении кода можно спорить вечно. У каждого будут свои уникальные решения, которые он будет считать верными, просто стоит посмотреть как другие делают, как разные подходы выглядят + от языка некоторые нюансы также зависят.
А ещё можно открыть свой очень старый проект и сразу понять, хорошо ли понятен код, легко ли его читать.
Как говорит святой отец в конце каждой проповеди моей церкви, используйте преттир и линтером с готовыми популярными пресетами, ибо это дело богоугодное
Про преттиер я написал в статье своё мнение. Опять же, оно субъективно, однако каждый может ознакомиться с разными точками зрения, и сделать свои выводы.
Ага. Иногда даже форматируешь код не совсем так, как хотелось бы – ибо встроенные средства автоформатирования среды не имеют тонких настроек, ставить какие-то сторонние плагины всей команде – геморрой, а форматирование, отличное от автоматического, рано или поздно поедет.
Код нужно писать так, чтобы было тебе удобно. Или согласно стандартов, которые у вашего работодателя есть.
Я вот лично видно стар уже стал, даже документацию стал вести. По функциям и переменным. Что они в проекте делают. Это все ты сегодня помнишь. А пройдет месяца три, уже и не вспомнить.
Чтобы понять что именно удобно, нужно пробовать разные подходы. Разные IDE. Постоянно развиваться, не стоять на месте. А когда человек попробовал единственный подход, а на все остальные ставит себе барьер, потому что ему не привычно, и новый подход не укладывается в его устоявшееся мировосприятие - это не значит, что ему не может быть удобнее. Это значит, что он сам ограничил себя от бОльшего удобства.
P.S.: Дока это хорошо 👍
P.P.S.: Ко мне обращаются и за доработкой проектов к-е я писал год или два года назад. Благодаря моей концепции организации файловой структуры проекта и кода проекта, мне не составляет труда восстановить понимание устройства проекта в быстрый срок, и внести доработки.
Шел 2024 год.
Фронты обсуждают как оформлять код
Не знаю есть ли вообще люди которые после пары лет кодинга не пришли самостоятельно как минимум к половине таких правил
Пример с балконными условиями - жесть.
Так писать не нужно вне зависимости от форматирования и количества пробелов.
Простые приёмы, которые сделают ваш код нагляднее