Comments 70
Python, в котором форматирование кода влияет на выполнение программы.
Слишком громкая фраза.
1. Не любое форматирование, а только отступы.
2. Не любые отступы, а только отступы блоков кода (сюда не входят всякие многострочные перечисления и тексты).
3. Отступы там гибкие, поэтому ничто не мешает использовать 1 пробел, и ваша программа точно так же не будет визуально читаться.
Короче питон — не исключение, там тоже можно напачкать.
С одной стороны вы правы, но сталкивались вы когда-либо с НАСТОЯЩИМИ юниорами?
Когда мы наняли одного такого в команду, то через неделю его уже не было, ибо мы делаем отступы чисто табами(так удобнее) и ситуация.
Мы передали код в котором отступы указаны табами, повсюду…
Возвращают нам код и… там пробелы.
(так удобнее)
А вот это вещь субъективная. Вот если там был жесткий стиль кода (что использовать, как форматировать и т.д. и т.п.), тогда совсем другое дело.
P.S. Какой язык-то? Вот например, в уже упомянутом Python-е, в PEP 8 так и написано:
Spaces are the preferred indentation method.
Tabs should be used solely to remain consistent with code that is already indented with tabs.
(Другие языки — Rust, Ruby, например — тоже не приветсвуют использование табов в коде. Хотя есть и противоположные примеры (Go)).
Так что если он полностью исправил все табы в коде на пробелы, и никакого формального стиля кода не было — то это, извольте, не его вина.
Речь идет о смешении табов и пробелов.
У нас в команде договоренность о своеобразном "поклонении табам").
При приеме в команду мы об этом предупреждаем.
Речь идет о смешении табов и пробелов.
У нас в команде договоренность о своеобразном «поклонении табам»).
При приеме в команду мы об этом предупреждаем.
Как много слов, которые сокращаются в два слова, если бы вы владели программерской терминологией.
Эти два слова — «Code conventions».
И не нужно никого предупреждать. Новому члену команды просто даётся ссылка на статью «Code convention» в Confluence. Или даже не даётся — он сам её ищет и читает.
2. Табы «в целом» скорее уходящая CodeStyle конвенция. Но например в Linux Kernel Code Style они родимые (не заменяются пробелами, да ещё и по 8 символов) — а оттуда зачастую попадают в CodeStyle контор занимающихся системным ПО.
ПС
Абсолютно с вами согласен, что увольнять! джуниара! вместо того чтобы объяснить! — это совсем какой-то моветон.
Джун на то и джун, чтобы учиться на работе, а не с ходу выдавать желаемый код.
.editorconfig — это формат, специально разработанный для того, чтобы не зависеть от IDE.
Ну и что это за «оговоренная перед началом работ IDE», простите? А браузер, которым сотрудники почту читают, вы тоже «оговариваете перед началом работ»?
Именно, так что вопрос «табы или пробелы» не возник бы:
indent_style = space
indent_size = 4
Общаться надо, не думать что «все всё и так знают». Не знают. Особенно человек со стороны внутреннюю кухню проекта.
Я в курсе. Вот эта ваша фраза «.editorconfig для (оговоренной перед началом работ?) IDE» подразумевает, что IDE надо оговаривать. Не надо. Надо просто держать .editorconfig в корне проекта, и не заставлять людей пользоваться какой-то там специальной IDE.
.editorconfig в 2020 понимают все (кроме совсем экзотики).
Ну вот старые IDE про .editorconfig могут просто не знать.
А ещё, для развивающихся языков, от IDE может зависеть максимальная поддерживаемая версия языка. Например, писать на C# 7.0 в Visual Studio 2015… можно, но в Блокноте это делать проще.
А ещё у IDE может быть какая-то особая интеграция со сборочными системами. К примеру, Visual Studio 2019 — это первая студия, которая идёт без своих плагинов к MSBuild для сборки веб-проектов.
Пальма первенства по кривоте тут, кстати, у Talend MDM Studio, где в зависимости от установленных плагинов будет отличаться поведение скомпилированного кода. Это единственная IDE из известных мне, где пришлось включать в гит пользовательские настройки.
Когда мы наняли одного такого в команду, то через неделю его уже не было, ибо мы делаем отступы чисто табами(так удобнее) и ситуация.
Мы передали код в котором отступы указаны табами, повсюду…
Возвращают нам код и… там пробелы.
У каждого могут быть свои личные предпочтения.
Современные IDE прекрасно умеют отображать код в части табов/пробелов именно так, как надо именно тебе.
Единственный затык мог быть в git/etc, где в коммит попадало бы гораздо больше строк, чем надо. Но это прекрасно решается хуками git, после чего табы/пробелы преобразуются автоматически.
1. В функции выполняется слишком много действий
обратная сторона — функции с одним действием, как советует какой-то очередной апологет. В итоге вместо чтения кода сверху вниз приходится прыгать по всему коду и куче файлов. Стало ли это удобнее? Нет. Стало ли кода меньше? Нет, стало больше.
Когда стоит делить:
Когда кусок кода используется в нескольких местах
Когда большую портянку возможно разбить на логические блоки
Пожалуй это все причины.
2. В проекте имеется закомментированный код
Чтобы искать в истории надо знать время и место. Закомментированный код показывает место, по нему же можно узнать время.
Или можно делать как в офисном холодильнике — если за n месяцев старый код не понадобился — удаляем его.
Тесты упадут не все, а только отосящиеся к выделенной функции.
Можно написать отдельные функции на действия. А саму логику реализовывать в какой-то одной основной функции. Там будет проще на алгоритм смотреть, особенно когда названия функций/процедур корректные. А сами функции а-ля одно действие можно использовать и в других реализация. Но я думаю нового здесь ничего не написано, это у всех в практике используется, для этого и создаются библиотеки, классы, пакеты и т. д. В книге Макконнелла об этом тоже много написано.
А константы тоже можно отель выделить, создав функцию, где они все заданы и там будет проще всего настройку менять, чем по коду скакать.
Единственное непонятно как это на производительности будет сказываться, если всё на элементарные действия разбить.
userPasswordIsValid($user, $salt.$password)
«Соль» нужна для увеличения стойкости пароля к перебору по словарю / брутфорсом. Если склеивать «соль» в начало пароля, то вся суть «соли» теряется, т.к. можно предварительно вычислить значение хэш-функции для данной «соли».
update А, я понял что имелось в виду.
Это самое зло, потому что может просто взорвать мозг.
HTTP_400_BAD_REQUEST = 400
и т.д. не только не понижает читабельность но еще и дает описание кода состояния
на первый недочет можно посмотреть шире, слишком большой класс, интерфейс вполне вероятно тащат слишком много на себе и стоит задуматься о возможной декомпозиции.
В какой-то известной книге читал)
Я Читала, что код портит переизбыток циклов.А один программист советовал использовать только for each.Не знаю, насколько это правильно.
В такой формулировке — «всегда портит, использовать только» — это ложь.
Имеет значение контекст, где именно.
Где-то желательно следователь данным установкам, а где-то — прямо-таки наоборот.
Foreach не даст вылезти за край списка и чётче выражает суть кода.
For гибче и особенно полезен при работе с абстрактными числами а не списками. Но его сложнее понять.
Это некорректно, потому что вы сравниваете потроха хаскеля с интерфейсом другого языка.
Всякие high order until, iterate и пр. — сокрывают рекурсию, предоставляя сходный циклу интерфейс, а как там в PHP (или где) под капотом foreach сделан — может и рекурсивно — интимное дело создателей языка.
Это если задача понятна любому, кто программу первый раз видит.
$cardDeckSize = 52;
Всё-таки лучше магические числа/строки засовывать в константы через define или const (если внутри класса), а не в переменные. А если они таки могут меняться хотя бы теоретически, то выносить в конфигурацию.
Пункт 2 это болезнь кода, который поддерживался при помощи контроля версий именуемой: Folder Copy-Paste
Пункт 5 — это не только у неопытных. Сейчас встречаю код, который писали опытные программеры, но на форматирование забили большой болт. Кошмар, а не чтение :(. Лечится введением нотаций форматирования и шпынянием этих самых "опытных" волшебными пенделями.
Недочёты, часто встречающиеся в программировании, которых стоит избегать