GTD
Программирование
Проектирование и рефакторинг
Совершенный код
Комментарии 224
+3
Функция больше 10 строк – слишком длинная.

Почему именно 10? Заголовок и скобки тоже включать?
Я правильно понимаю, что функцию такого вида нужно делить?
void foo()
{
    --7 строк кода
}
+3
не обязательно так буквально воспринимать, это же не закон в госдуме, чувак цифру назвал просто для ориентира.
0
Так а зачем тогда писать советы, если они взяты для ориентира, и каждый совет нужно тщательно додумывать с точки зрения опытного разработчика — как новичок может это сделать? Новичок поймет буквально — будет писать функции не более 10 строк.
А потом, через 5 лет, будет еще и других учить, что так делать правильно?
0

Если до него за 5 лет не дойдёт его ошибка, то у меня для него плохие новости

+2
Просто вы не программировали на форте. Там и в две строчки функция — уже слишком длинная.
+1
Там и в две строчки функция — уже слишком длинная.
Это смотря сколько в одну строчку писать:
примеры из nnCron:wakeup.spf
: SetWTimer ( pd h -- ior )
>R
>R
TRUE 0 ['] APCWTimer 0
R>
R> SetWaitableTimer ERR
;

: WakeAfter { ms \ ht -- }
WaitableTimer THROW TO ht
ms 10000 UM* DNEGATE SWAP SP@ ht SetWTimer THROW 2DROP
TRUE ms 10000 + SleepEx DROP
ht CloseHandle DROP
;

+3

Ерундовый совет. Если поток управления в функции прямой как палка и в ней нет каких-то кусков, имеющих потенциал переиспользования, то можно и функцию на 1000 строк написать без потери читаемости.

+2
можно и функцию на 1000 строк написать без потери читаемости.

Тут проблема будет не с читаемостью, а с переиспользованием переменных в рамках одной области видимости. Так что лучше разбить на логические изолированные куски и оформить в самостоятельные функции. И логика работы функции будет выражена намного яснее метаязыком названий внутренних функций.
+3
чрезмерное биение тоже может усложнить код — появляется куча непонятно как взаимодействующих друг с другом функций с не говорящими названиями
0
важно не только правильно именовать, но также чтобы атомарные функции были самостоятельными логическими единицами. Иначе, впрочем, говорящее название всё равно не выдумать
+2
Пардон за оффтоп, но прям к месту (на мой взгляд):
Совсем на днях сменил тактику разработки моделей в KSP — догадался, что не стоит делать «монолитные» изделия в сохранениях. Перешел как раз к более промышленной тактике: делаю отдельно те же ускорители / ступени / сегменты / полезную нагрузку (те же зонды/спутники). А потом уже по мере надобности из готовых сегментов собираю конкретный экземпляр под конкретную задачу.

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

Модульность — великое «изобретение» (на самом деле подход).
0
Там вроде есть мод, который позволяет сваривать такие модули в один. В итоге они вроде как считаются как один компонент, и игра тормозит меньше. Не пользовался, но видел что-то такое.
0
Сейчас в игре (кажется из коробки… но не уверен на 100%) есть при загрузке модели доп.кнопка «вставить» — вот она и позволяет в итоге делать сборку из нескольких частей.
Ирония в том, что я не сообразил изначально весь итоговый простор.

UPD: пардон, перечел еще раз ваше сообщение… кажется вы несколько об ином, хм… пойду опять шерстить CKAN.
0
Есть, но с ним свои проблемы. Сваривать можно только простые однотипные детали. Несколько баков можно объединить в один, а вот двигатель к баку, ЕМНИП, приварить не получится.
+2
Как только разработчик начинает покрывать свой код тестами, у него автоматически приходит понимание оптимального размера функции. Чем длиннее функция, тем сложнее для нее тест. Слишком короткие и тривиальные функции привносят накладные расходы по обмену параметрами между ними (именно организационные в коде, а не производительность). И та и другая крайность замедляет и усложняет разработку и сопровождение. У каждого свой баланс.
0
Может тогда не надо указывать какие-то конкретные цифры, а говорить, что функция должна выполнять только одну неразрывную операцию.
В моей практики была ситуация, когда в функции из 30 строк, при этом 20 из них занимало строки с переносом значений из распарсенного xml-файла в класс. Сами понимаете, что это делить не имеет смысла, т.к. нужно сделать всё или ничего.
0
Как раз-таки имеет. Написание теста на такую функцию сразу выявит, что конвертация XML в специальный класс — это одна задача, а манипуляция этим классом — другая. И проверять этот функционал проще, когда он разнесен по разным функциям, чем писать каскад тестов на всевозможные пересечения.
0
Я же написал, что файл распарсенный. На вход функции подавался готовый xml-документ.
+1

Иногда можно обойтись минимумом тестов. Если все компоненты, используемые в функции, оттестированы, возможность описок минимизирована с использованием системы типов, в функции нет ветвлений, то достаточно проверить пару случаев с известным входом/выходом, чтобы убедиться, что все требуемые шаги выполнены.


Это я про языки с развитой системой типов. В языках с динамической типизацией, тестировать естественно нужно всё.

+1
26-я ошибка. Я код напишу один раз и никто другой в него потом не полезет.
// Я через несколько месяцев == другой.
+1

От того, что в код залезет кто-то, кто не понимает, что ситуация поменялась, и нужно дописать ещё тестов, никакие тесты не застрахуют.

0
Тесты пишут не для того, чтобы застраховаться от изменений. Тест — это, в первую очередь, контракт, выполнение которого проверяется.
Когда код покрыт тестами, то любая доработка естественным образом мигрирует на TDD, так как сначала все равно нужно формализовать изменения контрактов.
Потому что в противном случае приходится держать контракт в голове, пока правишь под него код.
+1

В языках с развитыми системами типов некоторые контракты (переменная не может быть null, например) можно выражать с помощью этой самой системы типов. И они будут работать для всех входных данных, а не для некоторых входных данных, как в случае с тестами.


Другие языки, вроде Rust, ещё добавляют гарантии безопасности памяти, так что писать кучу тестов, для того что и так не сломается (последовательный вызов оттестированных функций, о котором я говорил) — совершенно не имеет смысла. Единственный реалистичный случай внесения сложной логики в такую функцию — рефакторинг, с переносом функциональности одной из вызываемых функций в эту функцию, но тогда будет несложно заметить и необходимость переноса тестов. И от того, что эту необходимость не заметят, тесты не защитят.


Или другим языком: единственный тест может покрыть все code paths, если на верхнем уровне этот code path один, а все подуровни уже покрыты тестами/правильность гарантирована системой типов.

0
единственный тест может покрыть все code paths, если на верхнем уровне этот code path один, а все подуровни уже покрыты тестами/правильность гарантирована системой типов.

Так тест покрывает только верхний уровень, т.е. логику выполнения самой функции, а не её внутренностей.
Это контракт: если на входе это, то на выходе должно быть то.
И простота данной схемы сразу выявляется функции, которые, вроде бы, не сильно параметризированы, но внутренняя логика зависит от состояния объектов, которые в неё поданы. И либо писать на каждое состояние объектов и их пересечение свой контракт (а нам все равно это надо делать, хотя бы разбираясь с тем, какая для каждого случая будет бизнес-логика), либо переписывать.
0

TDD + ООП та ещё смесь. Если рассматривать программу как способ преобразования данных, а не как групповое поведение кучи объектов, у каждого из которых есть своё поведение, всё становится намного проще. Это не всегда применимо, но если не смотреть на всё как на объект, то жизнь себе можно упростить.

0
Больше вопрос в том, покрываем ли мы тестами все случаи запрошенной бизнес-логики, когда реализуем её через умную функцию. Или отделываемся парой основных бизнес-кейсов, а остальные случаи проверять не будем, так как функция эта слишком умная и вариантов флоу в ней могут быть десятки, а бизнес просит только о двух.

А по факту перед нами может и всё правильно делающая функция, но не тестируемая из-за своей архитектуры. Переход на TDD, как раз, позволяет уйти от сложных и умных архитектур, как потенциально не тестируемых. Хотя без тестов они могут выглядеть очень даже красиво. Тесты позволяют видеть за этой красотой уязвимые участки кода и места совмещение функционала.
+3
Не используйте длинные строки. Строку длиннее 80 символов очень трудно читать. Используйте специальные инструменты для приведения кода в порядок (ESLint, Prettier для js).

Ограничение в 80 символов лично мне кажется перебором

+6
Тоже считаю, что много кому лучше использовать, например, с 120. Я в Python, например, пишу документирующий сам себя код, потому имена там длинные, но понятные. И если ограничение в 80 символов, то уж слишком много строк будут некрасиво переноситься на вторую строку, лишь ухудшая читабельность.
+1
Возможно перевёрнутый набок экран монитора detected. То есть в портретном режиме. Часто приходится видеть у программистов.
+1

А я просто люблю видеть несколько колонок кода на экране одновременно. Это очень удобно.

+1

Действительно.
Нет смысла тащить ограничение из времён DOS. Обычно выбирают так, чтобы строчка влезала на экраны у всей команды. И чаще это 110-130 символов, но не всегда.

+1
Это еще что. Я тут на работе столкнулся в ограничение в 8 символов в одной дорогой и в общем-то современной системе управления базами данных. Вот где настоящий хардкор) Причем не то чтобы не рекомендуется — нельзя сделать больше.
0

Название системы — три буквы?) За два с лишним года так и не смог привыкнуть к именованию датасетов вида "птчк", " упрлс"...

0
У неё ещё есть циферка 3 или потом 4 буквы :-)
Менять больше всего поразило в ней, что в ней есть ограничение по длине ПРАКТИЧЕСКИ на все поля. И диагностика ошибок нулевая или на уровне, что документ не сохраняется с формулировкой «Нельзя сохранить документ», без всякого объяснения почему…
0
Не угадали) Но видимо такие проблемы не только у Oracle с SID
0
ну честно говоря, это ограничение времен первых терминалов, где текстовый режим был 80 символов шириной. Да, он взялся от перфокарт, но на языках программирования все-таки писали на терминалах, а не на перфокартах.
0
На единственном промышленном языке программирования FORTRAN писали на перфокартах. Первые терминалы имитировали перфораторы.
0
Ну вы же не путайте.

На перфокарту переносили готовую программу для выполнения.
Саму разработку на перфокарте не вели.
0
Саму разработку вели на бумажке, прикинь. Потом специально обученные девушки (ну или сам программист) набивали её в колоду. А потом был прогон. Единственный. Потому, что вас много, а ЭВМ один.
+1
Дос-не дос, но надо не чтобы «строчка» влезла в экран, а «строчка 3 раза» (или в вашей практике 3-way merge не существует?). У меня от силы 3 по 100 влазит на 27 дюймов.
0
Кому как. Мне кажется очень удобным. Я привык работать за одним монитором на 24'', обычно открыто две колонки кода в вебшторме и иногда структура и/или файлики. И всё влезает, читать удобно. При 100-120 такое не пройдет уже. Надо будет подскролливать что-то. Да и читать короткую строку проще, на самом деле, глазки меньше бегают вправо-влево.
+1
У меня есть плоховидящий коллега, у него масштаб выкручен на 200% на 24" мониторе, и длинные строки соответственно, в него не помещаются.
0

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

0
Покупка сорокадюймового монитора увеличит расходы компании, и тем самым создаст ограничения всем остальным.
+1
Более того, любое количественное ограничение по длине строки это полная ерунда.

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

Разбиенеие одного вызова получения чего-то откуда-то на несколько строк ухудшает читаемость.

Те, кому надо сконцентрироваться на этой конкретной строке — прокрутят и прочитают.
+1
if (condition) then — логическая операция одна? Если то — думаю, да. А вот условие может быть аж на несколько строк А и Б или В и Г или НЕ Д… громоздить все сложное условие в одну строчку — ну, на любителя подход.
+1

Такое ограничение сохранилось не только благодаря досу, перфокартам и чему-то устаревшему, но благодаря тому, что чем меньше длина строки — тем проще делать дифф.


Будет ли удобно делать дифф для целого абзаца в виде одной строки? Кстати, поэтому и в Markdown сделали мягкие переносы, которые не разрывают абзац. На хабре правда они не работают, но это уже другой вопрос.

+18
26. ошибка читать такие статьи и считать что это эталон :D
-1
27. считать что количество пунктов — всегда кратное или красивое число.
0
Тогда можно и до 32 доводить. Хотя чего мелочиться, даёшь 256!
+8
Ну и классика:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
+1
0 Ошибка — использовать бездумно любые патерны, правила или советы из подобных статьей как единственный и непреложный закон. Всегда должна быть золотая середина и любые правила можно при необходимости нарушить.

Надо написать очевидный скрипт на 2 строчки — не пишите тесты, не используйте Dependency injection framework'и если у вас в проекте 3 простейших класса, не засовывайте паттерн проектирование только потому что можете.

В общем, при использовании любых правил — думайте сами насколько они вам нужны. Это сложно, но очень полезно. Иначе так и останетесь начинающими с 20 лет годами опыта.
0
Это не только о лучших практиках, это вообще о любых советах. Если Линус Торвальдс говорит, что у него очень хорошо пишется код, стоя на голове, не стоит считать, что лично вам писать код, стоя на голове, как-то поможет
+2
Надо написать очевидный скрипт на 2 строчки — не пишите тесты, не используйте Dependency injection framework'и если у вас в проекте 3 простейших класса, не засовывайте паттерн проектирование только потому что можете.
Надо быть с этим осторожным. А то потом окажется что «очевидный скрипт» со временем должен делать ещё что-то небольшое. И ещё немного. И ещё. И вот уже сраный монстр, который как-то незаметно, маленькими шажками, вырос из говнокода. И в таких процессах очень сложно поймать момент мол «не, всё, надо сначала переписать, а потом дальше развивать». Ведь всего чуть-чуть надо добавить, как всегда.
+2
Не надо выращивать монстра, разбивайте логику на небольшие модули, тогда такой проблемы не будет.

Ну и да, вы описали пункт 1 — «Программирование без планирования».
+2
Ещё раз — нужно будет поймать момент когда уже пора разбить логику на модули. И планирование тут не поможет потому что: «надо написать очевидный скрипт». Планируем — небольшой скрипт, не буду строить сложно. ОК. Проходит время — надо добавить буквально маленькую фичу в этот скрипт, чуть-чуть. Это ж не полный ребилд — нет. Значит дописываем в существующее. И так несколько итераций. В итоге большой говнокод, потому что в самом начале мы решили что «к чему тут сложности, маленький скрипт же». Не всё можно запланировать наперёд
+1
Про DI и фреймворки прям в точку. Пытаются даже в самый маленький проект запихать. Для простейшего http сервиса тащат Express =/
+2
А почему бы и нет? «Проиграть» какие-нибудь 10% производительности, и сэкономить кучу времени, даже на маленьком скрипте. Это же не дикий хайлоад где каждый такт важен. И не embedded devices.
+1
Я разработкой игр занимаюсь в последнее время (в данный момент на Unity3d). Насмотрелся уже как люди бездумно тащат в проект DI github.com/modesttree/Zenject. Производительность проседает, использовать правильно не умеют.

Помимо просадок по скорости такие громоздкие библиотеки требуют зачастую специфичных знаний, просто так бездумно использовать такие вещи не стоит.
+1
Игра — это не «простейший сервис», не так ли? ;) Вполне логично что в случае игр (где важен перфоманс) задумываться о зависимостях действительно нужно, тут я не спорю.
+1
Зависит от игры. Можно одну и ту же игровую функциональность сделать как с десятком мегабайт зависимостей, так и совсем без них.
+2
В случае с node.js не уверен, что написание простейшего http сервиса на Express будет быстрее, чем с использованием стандартной http библиотеки.

Но в целом посыл верен, если это позволит сэкономить много времени, при этом минусы такого решения не критичны, то да, почему бы и не воспользоваться.
+1
Дабы не быть голословным, две ссылки на две игры одного жанра (сити билдинг + походы, а-ля травиан):
github.com/sizeofcat/civitas
github.com/Areso/1255-burgomaster
Первая, правда, более богата функционалом, но начинались они примерно в одно и то же время с диаметрально разным подходом по отношению к зависимостям, и у обоих игр решение было принято на начальном этапе.
0
в играх вообще перформанс часто вступает в яростную борьбу с паттернами и архитектурой, привычными и допустимыми в других типах приложений
+6
Строку длиннее 80 символов очень трудно читать

Ну ё-маё! Сколько столетий должно пройти, чтоб мы перестали ориентироваться на CGA?
0
ограничение же не только в экране, но и в глазе.
по правде сказать я смирился. у меня prettier по умолчанию так настроен был и я не стал менять. Да, иногда раздражает автоперенос, но в общем терпимо
+2
"по правде сказать я смирился. у меня prettier по умолчанию так настроен был и я не стал менять. Да, "
В этой строчке 101 символ. Что у вас с глазами?
0
я не настаиваю что именно 80 надо. но как ориентир нормально.
а с этой строчкой что? за один раз раз не получается её охватить взглядом и несколько раз надо фокусироваться.
+3

На него с 14 века ориентируются, какой живучий однако формат мониторов.

+1
Еще там код надо было оборачивать обильным количеством комм рисунков.
0

Более того, не у всех десктоп с большим монитором и экран ноутбука с высоким разрешением)

+3
UNIQUE отслеживает уникальность величины столбца в масштабах всей таблицы. Идеально подходит для хранения логина или почты пользователя.

Нет не подходит. У таблице пользователей не может быть уникальных полей, за исключением id. Уникальным может быть только связка электропочта+valid range.
А если есть сервисные записи без почты или сотрудники без логина то и эта связка тоже не может присутствовать.

для процентов нужно проверять вхождение в интервал от 0 до 100

смотря для каких, есть множество случаев когда нужны отрицательные проценты или процент более сотни. Подобные преждевременные ограничения кстати очень распространенная проблема.

Одержимость производительностью

Спорный момент. Где грань, когда необходимость становицо одержимостью? Огромное количество проектов насилует сервера понапрасну, только из-за того, что лень было подумать над SQL запросами.

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

ох не всегда это работает, ох не всегда)

Ну и кроме всего прочего: KISS, YAGNI. Остальное от лукавого 8)
+1
Если пользователи могут обмениваться логинами (искать друг друга по ним), то лучше сделать их уникальными.
0
Пока вы не пользуетесь корпоративной почтой. Непочтовые логины должны бы уже умереть, ибо никто никогда их не помнит. А почтовые в пределах корпоративных доменов могут передаваться бесчисленное количество раз.
+1
Вы свой ник на Хабре помните? И я помню. А вот на какую из почт, да еще как написанную я его регистрировал, я вспоминаю каждый раз мучительно долго.
+2
Нет не помню. Изначально аккаунт был другой с моим традиционным ником. А почта у меня для всяких регистраций теперь одна.
0
Это в какой бд так?
заглянул в первую попавшуюся документацию, это было по SQL:
you can have many UNIQUE constraints per table…
для любого поля можно задать уникальность и оно будет соблюдаться в рамках всей таблицы
+1
Оратор выше вел речь не про физическую невозможность, а про логическую целесообразность.
Впрочем, я не согласен про логины, хотя соглашусь про почты (если они не выступают логинами). Я люблю регать на 1 почту несколько аккаунтов)
+2
Был сотрудник с почтой Вася Пупкин (vp@) мы его уволили, добавляем нового Виталий Пупкович (vp@) и начинается веселье. Причем чем больше сотрудников, тем веселее.

+3
На этом месте обычно отдел кадров запарывает кадровый учет в 1С.
-2
У нас всем сотрудникам выдаются легко произносимые почты из двух букв, дабы легко можно было диктовать/запоминать/итд Естественно они наследуются
+7
У нас всем сотрудникам выдаются легко произносимые почты из двух букв, дабы легко можно было диктовать/запоминать/итд

Самая потрясающая корпоративная идея тысячелетия!
Пишешь на почту vp@crazycompany.com и не знаешь к кому попадешь — к Василию Пупкину или он уже уволился и эту почту читает совсем другой человек.
А если Василий Пупкин уже работает в компании, то новобранцу Виталию Пупковичу дадут очевидный и запоминающийся логин ip или vu — логично же!
-6
Ах какой приятный выпад.
1. А вы желаете получить автоматический отлуп? Не нужно ничего знать, вам все расскажут.
2. Я так понимаю у вас сотрудники знают фонетический альфавит и могут легко диктовать vasyapupkin@crazycompany.ru? действительно идея тысячилетия
3. Вы явно не в продажах работаете да?) У второй компании адреса 01, 02, 03 У третьей m1, m2, m3. Это удобно и клиентам нра.
+1
1. А вы желаете получить автоматический отлуп? Не нужно ничего знать, вам все расскажут.

Естественно! Категорически не хочу, чтобы вместо юриста Пупкина наши договоры читал программист Пупкинович.
2. Я так понимаю у вас сотрудники знают фонетический альфавит и могут легко диктовать vasyapupkin@crazycompany.ru?

Собственно, все компании, кроме вашей, как-то справляются.
У второй компании адреса 01, 02, 03 У третьей m1, m2, m3.

Хм, да, очень удобно — клиент сразу понимает, что Василию Пупкину надо писать на vp07@crazycompany.com — логично и интуитивно!
-1
Естественно! Категорически не хочу, чтобы вместо юриста Пупкина наши договоры читал программист Пупкинович.

Для этого есть специальные адреса.

Собственно, все компании, кроме вашей, как-то справляются.

У многих торговых компаний короткие мыльца сейсас. А у мосигры например прикольные. Кроме того слышал как они справляются, по 10 минут на почтовый адрес, ага.

Хм, да, очень удобно — клиент сразу понимает, что Василию Пупкину надо писать на vp07@crazycompany.com — логично и интуитивно!

У меня почта 02 уже на многих доменах. Никто не жаловался.

ЗЫ А вообще в таком тоне мне общаться неприятно. Удачи вам с таким подходом.
+2
Для этого есть специальные адреса.

Ну вот, в случае юристов и реальной ответственности, здравый смысл как-то быстренько возвращается.

У многих торговых компаний короткие мыльца сейсас. А у мосигры например прикольные.

Да, вот, хоть на примере мосигры: если мы связываемся не с человеком, а с функцией, то вполне логично писать на invest@ или ecommerce@. А если мы пишем на короткий адрес hi@, то мы ожидаем, что это прочитает собственно Сергей Абдульманов, а не рандомный Христофор Иванов.

У меня почта 02 уже на многих доменах. Никто не жаловался.

Ну, конечно, глупо жаловаться, если неизвестно кто прочтет — уборщица или вахтер.
+4
У нас всем сотрудникам выдаются легко произносимые почты из двух букв, дабы легко можно было диктовать/запоминать/итд Естественно они наследуются

У нас писарь в уезде был, в пачпортах год рождения одной только циферкой обозначал.
Чернила, шельмец, вишь, экономил. Потом дело прояснилось, его в острог, а пачпорта переделывать уж не стали. Документ все-таки. Ефимцев, купец, третьего года рождения
записан, Куликов — второго… Культякин — первого. Да, много тут долгожителей.
из к/ф Формула любви
0
Я немножечко не въезжаю в местный сарказм видимо. Но раз вопросов никто не задает видимо все равно почему и зачем, ну ладно 8)
+1

В статье имеется ввиду преждевременная оптимизация производительности. Это писать код сначала понятно и просто, не заморачиваясь на оптимизации, просто потому, что код ещё несколько раз может поменяться. И вот когда код уже написан, он работает, покрыт тестами и выполняет задачу, для который написан, профилирование показало, что этот код работает медленно, вот только тогда стоит браться за оптимизацию. Да и то, тут ещё стоит рассмотреть систему в целом, а то может у вас больше тормоза даёт I/O, недели ваш код, и даже его оптимизация не даст ощутимого прироста.

0
Не соглашусь с вами. Писать запросы сразу надо нормально. Если у вас во всех местах, например, в условиях стоят всевозможные функции в запросах. То только все переделывать под ноль. Такое встречается постоянно
+1
Я и не отрицаю. Нормально != Преждевременная оптимизация.
В статье все же речь про языки программирования, а не языки выполнения запросов, потому что в последних свои нюансы, которые отличаются. И речь скорее всего про оптимизиции без предварительного профилирования, которые в большинстве не приносят существенной пользы, зато тратят время и даже могут ухудшать читабельность кода.
В общем, посыл такой, что не нужно заморачиваться на производительности при написании кода на языке программирования (не запросов), если эффективность этого кода не определена эмпирически и не доказана целесообразность увеличения его производительности. Иначе — это, с большой вероятностью, пустая трата времени.
0
>Огромное количество проектов насилует сервера понапрасну, только из-за того, что лень было подумать над SQL запросами.

И не меньшее — потому что было НЕ лень. Работал в проекте, где ВСЯ серверная логика была вынесена в СУБД. Ну и 150 запросов в минуту и не больше. После разделения логики и упрощения запросов, получили около 10К запросов в минуту.
+3
И не меньшее

Ну все таки меньше) Порок входа в это дело куда выше, чем в клепание простых запросов.

Работал в проекте, где ВСЯ серверная логика была вынесена в СУБД. Ну и 150 запросов в минуту и не больше. После разделения логики и упрощения запросов, получили около 10К запросов в минуту.

Странная корреляция. Я даже придумать не могу как можно было сделать так плохо.
+1
Порок входа


Понимаю, что очепятка, но как звучит!
+1
Вспомнил свой код с многократными повторениями, по 500 строк в процедуре.
Эх, детство у меня было замечательным.
Изменение разрешения экрана ради демонстрации пиксель-сцены.
Переменные а1, а1_0, аа, аа0.
Полное отсутствие каких бы то ни было проверок на наличие тех файлов, которые я честно-честно положил.
Карты местности в jpeg.

Могу сказать, что данная статья действительно полезна, но уже не для новичка. Новичок может и половины не понять.
0
Угмс, есть такое ощущение. Читаешь, и по значительному числу пунктов: «Да, помню, был у меня такой факап»…
+1
В п.13 однозначо справедливым мне кажется только последнее замечание, с которого и надо было начинать — что reduce плох тем, что не обрабатывает массив, если он длиной в 1 элемент, а тупо возвращает этот элемент, если не указано initialValue

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

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

А если программист передает объект в функцию, в документации которой описан четко тип передаваемых аргументов — это не создатель функции виноват.
+1

Категорически согласен, всего не предусмотришь. И, кажется, я знаю откуда у автора появилась эта паранойя — в Javascript'e, с его динамической и слабой типизацией, даже во вполне безобидном коде приходится писать проверки типов.

0

В языках с динамической типизацией одна и та же переменная может иметь разный тип, в результате ошибки или явно, но это факт и от наверного типа никто не застрахован. Более того, есть такое понятие, как duck typing, так что тут больше по интерфейсу матчинг, а не по типу объекта. Ну и Null, None, null, undefined и так далее никто не отменял, их как минимум нужно проверять.
А ещё если вы пишете библиотечную функцию и есть внешний клиентский код, который может передать в нее все, что угодно, проверки входных параметров все же стоит делать)

-2
Null, None, null, undefined — все эти варианты возникают не сами по себе, а потому, что какие-то другие функции их возвращают, что тоже является слабым и спорным приемом программирования

Если использовать прием «не возвращать Null, None, null, undefined» — то и проверки не будут нужны так часто
0
// В языках с динамической типизацией одна и та же переменная может иметь разный тип

это да, от этого особенно часто страдаешь, работая с чужими библиотеками
вот на приеме от таких функций, любящих подсовывать разные типы объектов и надо ставить проверки — главное, что не во всех своих функциях писать

в JavaScript использование одного типа является крайне желательной практикой — это позволяет движку V8 проводить дополнительные оптимизации после «разогрева», да и уменьшает вероятность ошибок в коде из-за того, что вы описываете )
+2
«высокое зацепление» в моем понимании это означает что класс должен выполнять именно то, для чего он предназначался и делать это превосходно, а не «что внутри класса должно быть максимально связей»
+8
У начинающего программиста всего две ошибки:

1. Недостаточно делать что-то.
2. Чрезмерно делать что-то.
+2
1. Недостаточно делать что-то.
2. Чрезмерно делать что-то.
Напоминает выход за границы массива.
+3
Правильный подход — это упорядочить ту часть комнаты, куда вы добавляете что-то.

Только в отдельной задаче. Иначе, в одном комите будет Ад и Израиль.
0
Или в отдельном, предварительном коммите. Иначе банальная лень (заводить тысячи задач, обосновывать необходимость каждой перед всеми заинтересованными лицами и т.п.) может погубить хорошее начинание.
0
Мы завели тип задач «улучшение кода» и доверили их дежурному. Иначе, при код-ревью задачу могут завернуть за правки, которые к ней не относятся и тогда будет не только обидно, но и проблемой для заказчика (грубо говоря, потеря денег).
0
Не используйте длинные строки. Строку длиннее 80 символов очень трудно читать. Используйте специальные инструменты для приведения кода в порядок (ESLint, Prettier для js).

Как оно там живётся в 90-х? Какие 80 символов? Кто еще пишет на калькуляторах код? Зачем это? 120 символов в строке можно смело писать. А если это какое-нибудь перечисление, то можно и больше символов.

Следите за количеством строк в функциях и файлах. Разделяйте код на мелкие части, понятные и тестируемые. Функция больше 10 строк – слишком длинная.

Тоже странный совет. Особенно в сочетании с предыдущим. А сотни функций с похожими именами, и содержащими по 7-9 строчек логики это лучше? 10 строк кода — это две объявленных переменных и два уровня цикла с одним if. Так себе перспективы.

Массив или объект?
Самая распространённая ошибка – это использование массивов вместо объектов для хранения списка записей. Да, вы не ослышались, для хранения списка записей нужно использовать объекты. Под списком записей я подразумеваю такие записи, где присутствует идентификатор. Массивы оправданы для хранения скалярных величин и если планируется активное добавление в массив.

Автор сравнивает теплое с мягким. Вроде идея-то правильная — «нужно использовать правильную структуру данных», но пример такой, что запутает любого. Наверное, имелось ввиду, что для записей с некоторым ключом нужно использовать такие «объекты», которые позволяют искать не за линейное время (упорядоченные таблицы, деревья поиска, хеш-таблицы, списки с пропусками и т.д.). Но идея выражена максимально невнятно. Да и если искать, например, не нужно, то и список пойдёт. В общем странный совет.
Не делайте так, если вы программист. А если вы работодатель таких программистов — увольте их прямо сейчас.

Надеюсь, это была такая шутка, а не максимализм.

А вообще, сама статья плоха именно потому, что постоянно мешает советы разного типа. Например совет проверять тип аргумента — бесполезен в строготипизированных языках. Не говоря уж о том, что во внутренних функций НЕ НУЖНО проверять аргументы методов и т.п. Нужно обеспечивать переход объекта из одного согласованного состояния в другое. И таких вещей в статье масса. Причём на каждое правило можно привести контрпример, когда так делать не надо. Удивлен, что не встретил такого заезженного и избитого правила, как «не использовать goto». Обычно в подобных списках советов он тоже встречается, хотя правило совсем неоднозначное.

П.С. В какой-то момент понял, что это перевод. Поэтому про остальное писать нет смысла. Зачем это переводить? Таких списков советов — полно. Их никто не читает, они субъективны чуть больше чем наполовину.
-1
эти правила формировались для несколько иного. программный код структурирован, он скорее двумерный, в отличие от линейного обычного текста. он подсвечен. не надо экономить бумагу. книжка станет менее прочной, если придать ей альбомную ориентацию, в отличие от монитора, и тд
+1

Если вы ожидаете от меня развернутой аргументации, стоило бы ознакомиться с ссылками, которые я привел. В приведенных статьях, говорится о том, что длина строки обусловлена особенностями поля зрения человека. Строки длиннее 90 символов вынуждают глаз совершать дополнительные движения, что приводит к утомлению.
При этом не имеет значения код это или стихи.

-2
Вы привели ссылки на текст, где это постулируется без должных доказательств.
А ссылки на исследования у вас есть?
Я вот знаю, что наоборот, к утомлению приводит статичный взгляд в одну точку. Да и по себе вижу, что так оно и есть. Работать за двумя широкими мониками менее напряжно, потому что чаще двигаешь глазами.
Да и все упражнения для снятия напряжения глаз — это движения ими, а не, наоборот, пассивация.
-1
Да судя по тому, что вам хоть в глаза нассы, глаза у вас такие крепкие, что и широкий текст им не навредит. Однако, среднестатистический читатель утомляется от чтения широкого текста.

Последствия нарушения правил типографики не очевидны для читателя. Он чувствует, что устал читать, но не понимает из-за чего именно. Шрифты, отступы, интервалы, засечки, колонки, думаете это все только декораций ради? Если вы заметите, то на всех популярных ресурсах ширина основного контента ограничена, а не растянута на весь монитор.

И в коде я тоже всегда использую две колонки, иногда в них даже открыт один файл в разных местах.

Я вот знаю, что наоборот, к утомлению приводит статичный взгляд в одну точку

Совершенно верно, поэтому ширина колонки не должна быть в один символ. Не нужно приводить глупые примеры.

Работать за двумя широкими мониками менее напряжно, потому что чаще двигаешь глазами.

Типографика — это про оформление текста, а не про организацию ваших окошечек. Два монитора — удобно. Слишком широкий текст — неудобно. Вы попробуйте на два монитора растянуть сплошной текст. Возьмите статью с хабра, вставьте ее в блокнот, растяните его на два монитора и прочитайте до конца (а лучше на три). Тогда вы поймете, что не нужно бросаться в крайности, и оптимальная ширина колонки взята не с потолка.

Короче не ту тему вы выбрали для спора.
0
хоть в глаза нассы

чо за быдлота на моем хабре?
попробуйте на два монитора растянуть сплошной текст

Не нужно приводить глупые примеры.


Шрифты, отступы, интервалы, засечки, колонки — где вы это всё увидели в программном коде?
Один шрифт, один интервал, никаких колонок. В программном коде свои способы организации текста — это отступы и подсветка синтаксиса. И читают программный код люди не подряд, они ориентируются на уровень вложенности в первую очередь, на цвет ключевых слов, на пустые строчки. Когда читаешь код, ты его не читаешь, как обычный текст, ты чаще что-то ищешь — нужный метод и возвращаемый тип, например. Вчитываешься намного реже.

Так что весь ваш дезигн головного мозга выплёскивайте в каментах к другим статьям
0
Мой пример экспериментально доказывает, что у текста должна быть разумная ширина. А общепринятые стандарты типографики, которые не без причины используются во всем мире, намекают, какая именно ширина.

Товарищ выше прислал вам ссылки ознакомиться, но вы попросили ссылки на исследования. А от вас можно ссылки на исследования получить, что широкий код — благо глазу? Или даже без исследований, есть где-нибудь признанные в IT-сообществе стандарты или рекомендации в отношении ширины кода в 120 символов?

Шрифты, отступы, интервалы, засечки, колонки — где вы это всё увидели в программном коде?


Везде, например? В любой профессиональной IDE, на любом профессиональном ресурсе (типа гитхаба или стека, и даже хабра) код и вставки кода имеют строго определенную типографику. Да, везде шрифты без засечек, моноширенные, узкая колонка. Могу забросать примерами. А вы можете найти пример, где по умолчанию пропагандируется широкий код? А не моноширинный шрифт? А уплотненный интервал?

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

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

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

Приведу пример:

Отступы есть? Есть.
Подсветка синтаксиса есть? Есть.
Одна проблема: типографики нет.

Глаза уже зачесались?

0
Ваш пример доказывает как раз мой тезис о том, что если бездумно применить правила типографики для текста к программному коду — получится херня.
Или даже без исследований, есть где-нибудь признанные в IT-сообществе стандарты или рекомендации в отношении ширины кода в 120 символов?

Вы, похоже, почему-то решили, что 80 символов — это некое божественное откровение, или на худой конец результат исследований в области эргономики.
Так вот, ни то, ни то :)
Это пошло с системы CGA, которая в своё время заняла рынок, все последующие были совместимы с ней, пикселей было мало, буфер памяти микроскопический, даже двойной буферизации не было. Они б, наверняка, хотели ретину, широкие моники и 8000p, но имели то, что имели — 4:3 ЭЛТ и 80 символов в строке.
Когда от тех ограничений со временем избавились, экраны стали расти вширь, угадайте почему :)
Но как раз в то время рождались многие операционки и языки программирования. Тогда не стояло вопроса, а сколько же символов в строке удобно читать — альтернативы не было. И с тех пор каждый раз когда вставал вопрос, что же рекомендовать пользователям, приходилось оглядываться на народ со старым железом.
Насчёт того, что якобы никто не ставил под сомнение целесообразность этого легаси — ставили, и много раз. Сколько руби существует? Лет 20 уже, наверное. Там ставили с самого начала. Синтаксис руби способствует составлению цепочек вызовов. И этот самый синтаксис с тех пор перекочевал даже в явовское stream-API, во многих новых языках такие вещи добавляют и на этом фоне всё более несостоятельным выглядит оглядывание на стандарт сорокалетней давности
0
В результате у меня ваш комментарий занимает едва ли 30% от ширины экрана (16:9).
0
Ваш пример доказывает как раз мой тезис о том, что если бездумно применить правила типографики для текста к программному коду — получится херня.

Мой пример лишь доказывает важность типографики, не более. А всплыл пример после вашего вопроса:
Шрифты, отступы, интервалы, засечки, колонки — где вы это всё увидели в программном коде?

То есть, это вы ставили под сомнение само наличие типографики в коде. Давайте повнимательнее, а то я уже устаю.

Вы, похоже, почему-то решили, что 80 символов — это некое божественное откровение, или на худой конец результат исследований в области эргономики.
Так вот, ни то, ни то :)

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

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

Вы проигнорировали мой пример с двухколоночным расположением панелей в IDE. Судя по всему, у вас одна колонка. Ну да и хрен с ним. А как быть с двухколоночным diff? Я им не пользуюсь, мне с головой хватает git diff, но я знаю, что многие пользуются. Как им ваш широкий код дифать?

Лично я допускаю в коде широкие строки до 120 символов, но таких строк должно быть немного, потому что мне уже такое читать тяжело, и значительную часть кода я стараюсь умещать в узкую колонку.

Про цепочку вызовов интересный аргумент, но руби тут не причем. Я цепочку вызовов могу сделать практически на любом языке на базовых механизмах ООП. Вот только я не понимаю, почему эта цепочка должна быть в строку? Вы понимаете, что подобным аргументом вы утверждаете, что цепочка вызовов должна ограничиваться шириной экрана? Это разве не смешно?

Да даже с точки зрения читабельности, гораздо удобнее цепочку вызовов читать в столбик, чем в строку, сравните сами:

# код здорового человека
datasource->get_data()
	->filter('first_filter')
	->filter('second_filter')
	->sort('some_field')
	->reverse()
	->slice(10, 20)
	->format()
	->render();

# код курильщика
$datasource->get_data()->filter('first_filter')->filter('second_filter')->sort('some_field')->reverse()->slice(10, 20)->format()->render();

Прошу прощения за пхп, взял самый попсовый язык.

А если в сообществе руби кто-то и ставил этот вопрос (который, как я понял, не одобрил электорат), то видимо идея не прижилась. Либо, нужны подробности.

-1
То есть, это вы ставили под сомнение само наличие типографики в коде. Давайте повнимательнее, а то я уже устаю.

Я ставил под сомнение применимость правил типографики для печатного текста (ну или даже вообще текста на естественном языке) к программному коду. Остальное вы сами додумали.
А как быть с двухколоночным diff?

Не знаю, как вам, нормальным людям при мерже важнее структура (отступы), чем всё остальное. И знаете что еще, есть такое удивительное изобретение, как скролл.
почему эта цепочка должна быть в строку?

Потому что гораздо лучше, когда код скомпонован логически, а не потому, что кто-то из консоли с ним извращаться будет, и его надо нарезать на строки где попало, куда 80й символ пришелся.
0
Я ставил под сомнение применимость правил типографики для печатного текста (ну или даже вообще текста на естественном языке) к программному коду. Остальное вы сами додумали.

Ну и я примером показал важность и применимость этих самых правил для печатного текста. Вы же взяли и соскочили. Сначала спрашиваете, где я вижу в коде типографику, на что я вам показываю, где же я вижу в коде типографику, а потом соскакиваете, что типа типографика в коде есть, и мой пример иллюстрирует важность типографики. Завязывайте, я серьезно.

Не знаю, как вам, нормальным людям при мерже важнее структура (отступы), чем всё остальное.

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

Потому что гораздо лучше, когда код скомпонован логически, а не потому, что кто-то из консоли с ним извращаться будет, и его надо нарезать на строки где попало, куда 80й символ пришелся.

И каким это образом мой восхитительный код в столбик не скомпонован логически? Разверните строку, чтобы она не переносилась узким хабром, ее один хрен неудобно читать.
0
Цепочечные вызовы — не единственный пример. В многословной яве и самое простое с логической точки зрения выражение может быть длинным, объясните мне пожалуйста, за каким чёртом его бить на куски, если мне из всей стройки важен только тип, который стоит в начале.
Например:
МойСуперПуперТип<Дженерик1, Дженерик2> переменная = ФабрикаЭкземпляровМоегоСуперПуперТипа.создать<РодительДженерика1, ПодтипДженерика2>(агрумент1, аргумент2, аргумент3);
уже 170 символов, я а еще даже кодить не начал :)
+2
В java10 появился local variable type inference, уже сокращающий ваш пример до 130 символов. А теперь представьте, что аргументы переданы в фабричный метод в порядке 3, 1, 2. И внезапно конец строки становится самой важной (с точки зрения подверженности ошибкам восприятия) её частью.

И знаете что еще, есть такое удивительное изобретение, как скролл.

Тогда в сторону уходит начало строки. Удобнее и быстрее читать не проматывая
0
Удобнее и быстрее читать не проматывая

Только вы забываете, что работа с кодом и чтение текста на естественном языке — разные вещи. Повторяюсь, но всё же: чтоб понять, о чем абзац текста, его надо прочитать слово за словом весь, в структурированном программном коде же куча метаинформации — подсветка, скобочки, структура. А читать его слово за словом приходится гораздо реже, чем навигироваться, смотреть в деревья иерархии, искать что-то и т.п.
0
давайте я поясню свою позицию на примере. Я сам пишу на плюсах и функция с сигнатурой аля const noexcept override — не редкость. Это целых 24 символа, и никого не смутит, если они заступят за границу колонки — их читать не обязательно, опущенный спецификатор либо не критичен, либо компилятор ткнет носом. Поэтому я иногда позволяю себе строки на 100+ символов. В вашем примере конец строки важен для понимания кода, поэтому, на мой взгляд, заступ нежелателен.
0
В моем примере (этого не видно, но) у параметров разные типы :)
А позиция у меня примерно такая же, думать надо, где важен конец строки, где нет. Если нет — то и пускай уползает за экран, на крайняк всегда можно до него доскроллить, и если это часто нужно — переформатировать. Но с умом, и где надо, а не везде на всякий случай.
И да, я не собираюсь думать о том народе, который хочет с телефонов покодить. Хочешь заниматься профессиональной разработкой — у тебя должен быть нормальный моник, а лучше два. А если уж сел временно за ноут, ну не делай две колонки, делай одну. Мне тоже приходится иногда так делать, но всё равно я под такие редкие эпизоды весь код переколбашивать не стану, мне важно то, насколько удобно с ним работать в типичной обстановке — т.е. на рабочем месте за стационарном компом с нормальным монитором
+1
ну вот у меня и коллег по два монитора. В «рядовом» режиме у всех ide в двухколоночном режиме на одном монике и браузер с доками на втором
0
У меня точно такая же схема, только на втором мониторе доки чередуются с терминалом сервера, на котором я отлаживаю код.
0
Повторяюсь, но всё же: чтоб понять, о чем абзац текста, его надо прочитать слово за словом весь, в структурированном программном коде же куча метаинформации — подсветка, скобочки, структура.

От того, что вы десять раз это повторите, истиной это не станет. Код, который не умещается в колонку и требует прокрутки по двум осям неудобно ни читать, ни редактировать, ни искать в нем нужную инфу, ни дифать. Короче аргумент с горизонтальным скролом плохой.

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

У меня всё умещается — это раз. Мне удобно — это два.
Вам тоже не следует то, как вам привычно, выдавать за универсальную истину. Можете посчитать, сколько раз здесь в каментах всплыла цифра 120.
+1
В чем проблема использовать продвинутый редактор/IDE, который умеет автоматически wrap текста?

Никто не говорит, что каждая строка кода должна быть 120-150 символов, но делать специальное ограничение в 80 для всего кода, если можно писать и 90 и 100 и 120 в строке, а не выдумывать как тут я сокращу название переменной, чтобы все влезно — вот тут я и ставлю вопрос — почему 80 символов это прямо такое правило?

нормальные diff-ы умеют автоматически переносить текст, и все красиво отображается.
+3
> 120 символов в строке можно смело писать. А если это какое-нибудь перечисление, то можно и больше символов.

Тут есть один нюанс — эти символы потом кому-то, вполне возможно, придётся читать.
+1
Я скажу так — никогда не следите за количеством символов в строке. Если вы вынуждены следить за этим самостоятельно (при помощи настроек в IDE, или вообще вручную) — это совсем плохо. Все правила форматирования кода должны проверяться на серверах сборки, и/или в pre-commit хуке. Только так вы не допустите нарушение этого правила, в противном случае — напрасная трата времени.
0
Вот, пожалуй, самый правильный совет. Который можно обобщить до «автоматизируйте рутинные вещи».
0

Правильно пишете. Это должно быть привычкой и на уровне автоматизма. А ещё проверяться линтерами)

0
120 символов в строке можно смело писать. А если это какое-нибудь перечисление, то можно и больше символов.
А лучше вообще все элементы перечисления в одной строке — чтобы люди не пользовались слишком уж простым git blame и более глубоко прокачивали навыки работы с системой контроля версия и shell скриптами.

Нет, я лично вообще за 140 символов (впрочем код у меня, в основном, на Java, а она многословна), но, по многолетним ощущениям, код лучше поддерживается если одна строка содержит не больше одной мысли или «семантического объекта»
0
если VCS встаёт на пути к достижению красоты кода в HEAD, что-то вы делаете не так.
Код читаешь явно чаще, чем блэймы, да и вообще, в историю лезешь только косяки разбирать, не было косяков — наплевать, что там в истории вообще было.
+1
Как оно там живётся в 90-х? Какие 80 символов? Кто еще пишет на калькуляторах код? Зачем это? 120 символов в строке можно смело писать. А если это какое-нибудь перечисление, то можно и больше символов.

У тех, кто использует IDE в двухколоночном режиме, на среднем мониторе ширина колонки 85-100 символов. На ноутбуках и того меньше. А фича, между прочим, удобная
0

Коллеги с экранами ноутбуков 1280x800 (стандарт на ноутах старых моделей) скажут вам "спасибо" за 120 и более символов. Потому что 80 символов позволяют открыть два файла с кодом на таком экране и ничего не будет переноситься)

+2
Завтра кто-то захочет открыть этот код на калькуляторе каком-нибудь в 4 столбца. И что теперь? По 20 символов в строке писать? Да, я, конечно, смотрю со своей колокольни (17 дюймов ноут, а на работе два больших экрана). Но кто мешает сделать автоперенос лишних символов в вашей среде разработке? Как, например, в Notepad++. А всем, у кого большие экраны и 120 символов норм.
-2

Ну с таким подходом непонятно, почему все должны под вас подстраиваться) А почему не взять тогда уж все 320 символов? И больше ж кода то влезет на экран и будет стимул всем мониторы обновить. Я вам так скажу. Есть рекомендации (например, pep8 в Python), которые не с потолка взяты, а следовать им или нет — ваше личное дело. В команде, как правило, code conventions принимают либо на базе общепринятых рекомендаций, либо на базе мнения большинства. Если в вашем случае большинству удобнее со 120 символами — ради бога. А в статье приводятся общепринятые рекомендации, а следовать им или нет — каждый сам решает

-1

И калькуляторы тут не причем, я вам привел пример наиболее распространенного разрешения на ноутбуках. И большинство ноутов старых моделей именно с таким разрешением. И именно 80 символов позволяют на таком разрешении делать 2 колоночный просмотр кода без переноса строк. И это одна из причин такого выбора

+1
На число символов влияет всё-таки не разрешение, а диагональ, при условии, что работа с устройством идём с фиксированного расстояния. Я понимаю, что открыть две страницы кода на 13" мониторе со 120 символами сложно, но я вообще не могу на таких маленьких мониторах что-то продуктивное делать, мне банально тесно. Вообще этот спор в какой-то мере о вкусах и удобстве. Кому-то неудобны длинные строчки, кому-то переносы на пустом месте и куча свободного пространства справа. Но апелировать к «общепринятости» в статье я бы не стал — автора статьи явно js укусил (ничего не имею против js) и некоторые советы там вообще спорные или относятся только к js. Сode-style в питоне относятся всё-таки к питону, не знаю, может разработчики питона все сидят на 13". А то так можно вспомнить какой-нибудь археологический язык, где нужно оставлять 5 пробелов слева для названия метки. Тоже code-style. Но писать про 80 символов я бы не стал в общепринятых советах, нужно находить компромисс между удобством и обратной совместимостью с калькуляторами. А самый лучший совет уже писали — использовать автоматические средства для форматирования + автоматический перенос.
0
Прогресс не стоит на месте и профессиональная разработка сейчас идет на больших мониторах. А значит, ничего такого, чтобы поменять правило 80 символов под новое время нет, думаю.

Кроме того, про все языки программирования не знаю, но если дело касается кода, то превышение 80-120 символов в строках происходит редко, и на удобство чтения кода на любом мониторе влияет не сильно.
0
Оригинал
— Using lists (arrays) instead of maps (objects) to manage records
The most common data structure mistake is probably the use of lists instead of maps to manage a list of records. Yes, to manage a LIST of records you should use a MAP.

Перевод
Массив или объект?
Самая распространённая ошибка – это использование массивов вместо объектов для хранения списка записей. Да, вы не ослышались, для хранения списка записей нужно использовать объекты.

Немножко настораживает, что так называемый «full-stack» девелопер не знает слова map.
0
Я знаю слово map и дальше идет пояснение, что это структура «ключ-значение» (что в привычном мне js соответствует объекту). А как лучше было перевести по вашему?
0
структура «ключ-значение»

может быть массив структур «ключ-значение»
Хотя тоже коряво.
Вроде есть одна структура «ключ-значение». А потом их становится много — массив из них. Array of structs — вроде такой термин, к примеру, в BigQuery используется. Правда там структура не обязательно «ключ-значение»…
+2

Я бы перевёл как "хеш-таблицу" (немного вольный перевод, но зато сразу понятна идея) или "ассоциативный массив" (точный перевод, но не очень очевидный).

+3

Ассоциативный массив — это точное название типа данных.

+1
Не совсем так.
Ассоциативный массив — это тип «интерфейса» структуры данных. Реализации могут быть разными — «хеш-таблица», какое-либо дерево поиска и т.д.
Хэштаблица — это конкретная структура данных (на самом деле, не совсем, там тоже есть разные стратегии разрешения коллизий.)
А общая рекомендация проста — не используй для поиска элемента плоские структуры.
+1
А как лучше было перевести по вашему?

[Один из пример ошибочного использования структур данных — это ...]
— Использование списков (массивов) вместо ассоциативных массивов(*) для обработки записей(**)
Возможно, самая частая ошибка, связанная со структурами данных — это использование списков вместо ассоциативных массивов для обработки списков записей. Да, верно, для обработки СПИСКА записей нужно использовать АССОЦИАТИВНЫЙ МАССИВ(***).
Заметьте, когда я говорю о списке записей, я имею в виду, что каждая запись должна иметь идентификатор, который будет использоваться для поиска. Использовать списки для скалярных значений — нормально и зачастую даже предпочтительно, особенно если мы в основном добавляем значения в список.(****)

(*) — вот то, что в оригинале maps ( в скобочках objects ) — это какой-то джаваскриптизм, который не способствует пониманию, по-моему его можно опустить ( тем более, что дальнейшие упоминания джаваскрипта вы подрезали)
(**) — «запись» — немножко устаревший термин, я бы потестировал на людях, не будет понятнее здесь везде вместо «запись» писать «объект». Смысл тот же, хотя и не дословно.
(***) — автор КРИЧИТ, ну и мы тоже будет, нуачо?
(****) — дабл неловкость, во-первых потому что что-то не придумывается благозвучный перевод этого «focus of usage», во-вторых потому что автор что-то по-моему загнался ( и почему «pushing» в кавычках?)

Вот примерно такое я придумал за минутку.
0
terrier, спасибо, исправил «объект» на «ассоциативный массив».
Как я понял автор имеет ввиду когда используют обычный массив:
[{id: 1, title: "entry1"}, {id: 2, title:"entry2"}, .... ]

Хотя лучше использовать ассоциативный массив:
{ 1: {id: 1, title: "entry1"}, 2: {id: 2, title:"entry2"}, ....}

И предлагает использовать обычный массив, только если нам нужно активно пользоваться Методами типа push, pop, shift, unshift (которые обращаются к записям не через ключ, а ориентируюсь на порядок в списке).
+1
Ваше замечание сильно объяснило тот бред, который был написан в этом пункте. Да, в исходном тексте было корректно написано, а вот в переводе уже ерунда какая-то.
+3
Так воот как это казывается! Всегда ненавидел такой стиль и теперь даже знаю его название и зачем он нужен.

Имхо, решать костылями то что должно (в идеале) проверяться другими методами — не верно.
0
Ну так в 2018 году IDE, линтер, статический анализатор, а то и компилятор не дадут проглядеть if (user = 0)
+3
const daysInYear = 365;


Никогда не делайте так. Понимаю, что это просто пример, но, не дай бог, кто-то так в реальном коде напишет. По поводу заблуждений программистов о времени — была хорошая статья, здесь, на хабре. Начать читать можно здесь https://habr.com/post/313274/ — много удивительного можно узнать.

P.S.: Для примера можно использовать безопасный аналог — const monthsInYear = 12; Месяцев в нашем календаре всегда 12.
+1
Конкретно такое вполне может попасться в банковском коде для депозитов и кредитов.
+2
const daysInYear = 365;
Никогда не делайте так
А так можно:
const integerPartOfDaysInUsualYearInMostCalendarsInEurope = 365;
?
Или лучше писать в коде 365?
-1
А можете привести ситуацию когда вам нужно значение «обычно в году 365 дней»? Если вы знаете год, можно посчитать кол-во дней точно.
0
В тех случаях, когда погрешностью можно пренебречь + облегчить код за счет отсутствия зависимостей, которые выясняют сколько дней в каком году.
Плюс мы облегчаем интерфейс пользователю, когда не спрашиваем у него в обязательном порядке в каком году он хочет открыть депозит или кредит или whatever что он хочет там сделать или посчитать.
+1
И снова ошибка. Каждый 100-ый, но не 400-ый год не является високосным, так что:

const daysInYear = 365.2425;
+1
Это в современном календаре так (в одном из). А в реальности это число колеблется и изменяется (Земля медленнее вращается вокруг своей оси).
+1
Ага, и это в пункте про важность качественного кода. Кстати в оригинале автор уже осознал и поменял на
const answerToLifeTheUniverseAndEverything = 42;
+3
if (b % 2 === 1) { // If the current number is even

Вот тоже зло в чистом виде: комментарий не соответствующий коду.
+3
Восхитительно. (
Если вкратце — «Пишите хорошие программы, а плохие — не пишите».
К сожалению, у большей части указанных ошибок нет внятных численных критериев. А значит если я даже искренне хочу воспользоваться ценным материалом статьи — то… как? Любая написанная программа которая работает — это лучшее, что сделал программист в существующих условиях. Объяснить как и главное — почему можно сделать лучше — может только более умный/опытный программист в каждом конкретном случае.
+1
«Изобретать велосипед» по-английски будет «reinventing the wheel». Мелкий огрех литературной адаптации.
0
Ошибка 26. А зачем я вообще влез в это программирование когда ничего не получается?
Раз влез, терпи, упорство и труд все перетрут
0
Что за js-дичь я только что прочитал?
В то же время заучивание сильных и слабых сторон разных структур данных вашего языка программирования, несомненно, повысит ваше качество как разработчика.
Самая распространённая ошибка – это использование массивов вместо объектов для хранения списка записей
Ну и расскажите мне, как я в ванильном си, узнав самую распространённую ошибку в структурах данных среди новичков, буду ходить по объекту (ага), который представлен ассоциативным массивом/словарём (ага) со стринговыми (ага) ключами, чтобы интерпретатор (ага) в рантайме мне нашёл (ага) содержимое этого самого т.н. «объекта», да ещё и сделал это быстрее (ага) массивов. Код новичка, млин.
Пользуйтесь командой git blame, выдающей автора каждой строки кода.
Пользуйтесь им везде. В Subversion, в Mercurial, в Team Foundation, вместо вечерней молитвы и в качестве приветствия. Просто бездумно запомните git blame и не забывайте почаще отрабатывать джебы по груше. Потому что «Не использование систем контроля версий (Git)». Потому что исключительно front-end open source на github в vs code. Потому что иначе вы пользуетесь примитивными инструментами из старой кладовки и не любите снуды.
И снова это не про сравнение парадигмы функционального программирования с остальными.
С какими остальными? Неправильными и неверными, потому что не модными? Конкатенативными и Логическими? Какими? Или, типа, всё-таки в очередной раз пошёл срач про модность в противостоянии Императивной и Декларативной парадигм?
+1
Советы не универсальные, местами противоречат друг-другу и требуют различной интерпретации в зависимости от ситуации. И следовательно на мой взгляд они для начинающего бесполезны. Потому что у него скорее всего нет ни умений, ни знаний чтобы их правильно интерпретировать. А если умения и знания есть, то он и без этих советов разберётся.
0
Кажется новичку полезнее набраться знаний по матчасти и ориентироваться в ней, чтобы хоть один из этих пригодился.
0
вот я новичок, как мне оценить качество кода, если альтернативы мне неизвестны?
0
Смотреть код, который тщательно поддерживается и курируется. Это если нужен чужой код для сравнения со своим.
Есть обратный вариант. Пишите статью на Хабр, в ней приводите небольшие кусочки кода и ссылку на проект, впадаете в депрессию от комментариев и общей оценки ваших трудов и заканчиваете жизнь самоубийством.
+1
Если вы можете безболезненно поддерживать и расширять вашу программу — у вас хорошее качество кода.
+1
Смотрите. Если автор не может расширять свою программу — это плохой код.
А если автор может расширять свою программу, то это не признак отсутствия плохого кода.
Потому что другой человек откроет, не поймет ничего и ужаснется — значит это плохой код, но автор в состоянии его поддерживать.
0

Очень спорная статья. Минимум к 6-10 пунктам можно нпписать замечаний.

+1
Маленькие коммиты с осмысленными заголовками помогут сопровождающим код людям понять, как шаг за шагом образовывалась программа, пока не достигла текущего состояния.

Представил ситуацию, когда мой код коммит за коммитом кто-то так сопровождает.
Варианта два:
1. Это библиограф, а я Билл Гейтс. Мертвый.
2. Это ботаны из УИТ ЦИБ ФСБ. А я в Лефортово.
+1
Справедливости ради нужно сказать, что есть и третий кейс: прибегает клиент с выпученными глазами и говорит, что в таком-то флоу в таком-то кейсе баг. А на самом деле это не совсем баг (или совсем не баг), а результат несогласованных требований к данному флоу, выставленных в разное время (а спецификация, разумеется, отсутствует). И вот тогда действительно приходится брать лопату и послойно разбираться, читать комментарии к коммитам и ссылаться на таски, попутно поясняя, как именно их взаимодействие привело к текущему результату.
0
Мне кажется для таких «поломок» хватает анализа пары последних коммитов. А если послойно и скурпулезно с самого начала — это скорей первые два варианта.
0
По поводу «Не гуглить» — по смыслу этот заголовок не подходит: я бы лучше написал, нет «тупому» копипасту. Замечание относится конечно же к первоисточнику, а не к переводчику.
-1

Насчет першого пункта. Пока сам что-то не закодишь в уме это совсем никак не работает, а вот когда что-то написано, то все сразу хорошего видно

0
Не пишите статьи типа «ошибок программистов», если вы сами не программист и не имеете хорошего опыта.

«Новичкам можно посоветовать такое правило: любой недокументированный код, который вы не понимаете — плохой.»
С какой стати код плохой? Он недокументирован, это плохо. Но с чего ему быть плохим?

Очень много из 25 примеров в статье даны с неправильным толкованием.
0
Автор статьи с нормальным опытом, уже не первый человек переводит его статьи для хабра, они вызывают интерес как минимум, и с медиума в рассылке они не просто так приходят — а значит у них высокий рейтинг и одобрения и читаемости.

А код плохой — это что-то типа презумпции невиновности, только наоборот. Если не понимаешь код — не говори, что он хороший, пока не поймешь. Говори что хороший, только когда полностью понял. То есть призыв сомневаться, понимать и проверять. А не клеймить.
0
«Новичкам можно посоветовать такое правило: любой недокументированный код, который вы не понимаете — плохой.»


А код плохой — это что-то типа презумпции невиновности, только наоборот. Если не понимаешь код — не говори, что он хороший, пока не поймешь. Говори что хороший, только когда полностью понял. То есть призыв сомневаться, понимать и проверять. А не клеймить.


Взаимоисключающие параграфы. То вы говорите, что код плохой, то вы говорите, что не нужно клеймить.
Так не нужно говорить что код плохой или код хороший, пока не понимаешь что он делает. Просто нужно либо ничего не говорить, либо говорить «я не знаю, не разобрал еще». особенно, если это новичок.
+1
А, я нашел в чем дело:

«As a beginner, you should just assume that any undocumented code that you do not understand is a candidate for being bad.»
«Новичкам можно посоветовать такое правило: любой недокументированный код, который вы не понимаете — плохой.»

«candidate for being bad» и «плохой» — так переводить не нужно.
0
Спасибо за замечание, пока думаю как исправить.
Первое что пришло в голову, «потенциально плохой», «кандидат на звание плохого», кажется не звучит. Еще подумаю немного и исправлю.
+1
Пункт №0 Не думать про экономику проекта
17) Не ориентироваться на конечного пользователя — должен быть №1
26) Не задавать себе вопрос «а зачем»?

Про тесты не хочу холиварить, но это тоже про экономику. На этапе тестирования идей и поиска бизнес-модели тесты вредны.
+1
Программирование – это на 90% изучение существующего кода и его изменение посредством маленьких, легко тестируемых порций, вписывающихся в общую систему. Само написание кода это всего лишь 10% работы программиста.

Программирование – это не просто написание строк кода, а творчество, основанное на логике, которое надо развивать в себе.


Ни прибавить, ни убавить

0
Честно говоря, я бы убрал половину, т.к. эти советы больше путают, чем помогают.
Вот например про комнату с одеждой. Есть одно большое правило, Работает — не трогай. Т.е. как только начнешь делать уборку в комнате хотя бы отдельного участка, так за ним посыпется все остальное. Без глубокого понимания того всего бардака и что с чем связано убираться очень опасно. А новичек уж точно не сможет ни разобраться ни поменять, а только что ни будь похерит, как уборщица на столе инжинера…
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.