“Чистый код”: пять ключевых моментов из обязательной к прочтению книги для программистов

Можно только гадать почему не использовался такой вариант:

cls.last_label = 0  # reset intenal counter

Может из-за того, что в будущем (для сброса) потребуется больше 1 действия. Ответить сможет только автор кода, если вспомнит.

По поводу printHelloWorld(): вы сами ответили на свой вопрос.
Как минимум снизится шанс опечатки. За счет того, что действия находятся в 1 месте.
Отсюда следует другой плюс: чтобы изменить эти действия придется внести правку в 1 место, а не искать все места с копипастой по всей кодовой базе.
Насчет быстродействия: на абстрактном примере нельзя дать никакой другой рекомендации кроме "код надо писать для человека" (ибо может оказаться что узкое место вообще в другом месте и т.п.).

И самое главное (снова имхо): на подобные вопросы нет однозначного ответа. Все зависит от контекста.

“Чистый код”: пять ключевых моментов из обязательной к прочтению книги для программистов

1. Вы (как человек работающий с этим кодом) понимаете смысл действия cls.last_label = 0?
   Я — нет, но благодаря этой функции я смогу сбросить label.
   Итого:
   
   • функция выглядит полезной
   • комментарий не соотносится с названием функции.
2. Функция printHelloWorld() нужна в том случае, если определенный набор действий (print("Hello, world!")) повторяется больше 2х раз многократно.

P.S. Все вышесказанное = имхо.

Функциональное программирование в Python. Генераторы, как питонячий декларативный стиль

gen_cat(consumers) в примере входит внутрь каждого контекста genfrom_queue

Как он может зайти внутрь каждого контекста, если genfrom_queue() никогда не выйдет из вечного цикла, т.к. StopIteration никогда не появится в очереди (см. блок "т.к." из моего предыдущего сообщения)?

P.S. Попробую с другой стороны:
Если приглядеться, то можно увидеть, что (в данном конкретном примере) consumers содержит результаты 3х вызовов genfrom_queue(in_q).
Чем эти 3 вызова genfrom_queue(in_q) отличаются друг от друга?

Функциональное программирование в Python. Генераторы, как питонячий декларативный стиль

Вопрос касательно кода из примера "Маршрутизация данных на генераторах (мультиплексирование, броадкастинг)":

1. будет ли работать этот код с разными очередями?
   Я так понимаю что нет.
2. для чего нужен gen_cat(consumers) в multiplex()?
   Я так понимаю что не нужен, нас интересует только genfrom_queue(in_q).
   Т.к. (при текущей реализации) gen_cat() никогда не дойдет до 2+ элемента sources,
   т.к. sendto_queue() никогда не дойдет до StopIteration,
   т.к. в follow() бесконечный цикл.

Кодер или кулинар? Тест для очень голодных айтишников

def append(element, seq=None):
  if not seq:
    seq = []
  seq.append(element)
  return seq

Какая-то косвенная проверка. Может лучше явно проверять именно то, что было написано? Т.е.:

  if seq is None:

Функциональное программирование в Python. Генераторы, как питонячий декларативный стиль

Именно так.
Я считаю что это ограничение должно быть явно указано в статье.

Функциональное программирование в Python. Генераторы, как питонячий декларативный стиль

Собственно, следующий пример имеет аналогичную проблему:

# statement-based while loop
while <cond>: 
    <pre-suite> 
    if <break_condition>: 
        break
    else: 
        <suite> 

# FP-style recursive while loop
def while_block(): 
    <pre-suite> 
    if <break_condition>: 
        return 1 
    else: 
        <suite> 
        return 0 

while_FP = lambda: (<cond> and while_block()) or while_FP() 
while_FP()

Если запустить, то получим следующий вывод:

IMP -- quit
FP -- quit
quit

FP версия делает 1 лишнее действие (по сравнению с IMP).

Функциональное программирование в Python. Генераторы, как питонячий декларативный стиль

# Normal statement-based flow control
if <cond1>: 
    func1() 
elif <cond2>: 
    func2() 
else: 
    func3() 

    # Equivalent "short circuit" expression
(<cond1> and func1()) or (<cond2> and func2()) or (func3()) 

"Equivalent "short circuit" expression" НЕ является эквивалентом "Normal statement-based flow control". Пример:

>>> func1 = lambda: print('func1')
>>> func2 = lambda: print('func2')
>>> func3 = lambda: print('func3')
>>> x = 1
>>> (x == 1 and func1()) or (x == 2 and func2()) or (func3())
func1
func3
>>> if x == 1: func1()
... elif x == 2: func2()
... else: func3()
...
func1

Разница в том, что с if'ом func3 не вызывается.

Мёртвый код: найти и обезвредить

И вот сидишь, как дебил, читаешь это сообщение и думаешь: ну и что же изменилось?

Никто не скажет вам что изменилось. Обратите внимание на то, что было сказано выше:

раньше у нас в аппсторе всегда было написано Bugs and improvement fixes, теперь появился человек, который тестирует различные формулировки в истории и их влияние на основные метрики

Я понимаю это так: "у нас есть метрики, мы будем на них воздействовать посредством changelog". Соответственно, там может вообще не быть ни слова про сделанные изменения, если это не влияет на метрики. Другими словами: содержимое changelog определяют метрики, а не изменения.

P.S. Имхо: подобные приложения стоит расценивать как интерфейсы, у которых есть только одна версия — актуальная.

Ох уж этот std::make_shared…

Это совершенно точно не типичная статья в желтой прессе, ибо ценность информации в типичной статье желтой прессе стремится к 0.

Лично я не знал такие подробности, поэтому данная статья позволит будущему мне сэкономить время (если вдруг придется копать в эту сторону).

Лучшие практики, эмпирический опыт и математика

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

Объединяем функции логическими операторами в C++

Шашкель и Шкалка для программистов на Плюсах заходят плохо (синтаксис категорически разный)

Особенно плохо заходят функции вида:

:.

9 советов для Windows Terminal от Скотта Хансельмана

Вот бы плагин для vscode чтобы редактировать настройки wt как настройки самого vscode…
Или хотя бы файл конфига со всеми доступными настройками как в sublime text 3.

День смерти стандартной библиотеки

Ради новых концепций, которые в плюсах не заложены (при этом иногда реализованы, но через костыли).

День смерти стандартной библиотеки

Все никак не могу понять: если сломать ABI, то какой смысл оставаться на С++?

Буквально на днях (в рамках "олимпиады" посвященной переписыванию wc) в очередной раз стало понятно что компиляторы разных языков выдают примерно одинаково работающий бинарь.

P.S. Я не против плюсов и своей профессиональной деятельности использую 2 языка: С++17, Python27.

wc на D: 712 символов без единого ветвления

Не надо стрематься. С нетерпением ждем продолжения %)

Ошибки переводчиков, которые привели к катастрофическим последствиям

Интересно, откуда пошла эта подмена ("экспертиза", а не "компетентность")?.. В последние пару месяцев это встречается очень часто.

Размышления на тему ООП и состоянии объектов

В хаскеле раздрядность Int тоже 64, так что все честно.

P.S. по крайней мере у меня такая разрядность...

GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Prelude> maxBound :: Int
9223372036854775807
Prelude> import Data.Bits
Prelude Data.Bits> bitSizeMaybe (0 :: Int)
Just 64

Мне нравятся картонные человечки

А раньше, чем через полгода не было вопросов, а пошел ли работник туда, куда его послали.

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

сами этой статьей пожаловались аудитории хабра

Почему эта статья считается нытьем? Автор поделился неплохой идеей (банальной конечно, но не все о ней знают/задумывались) и для упрощения выразил это в форме «личной истории».
Нигде ведь нет фраз в духе: «как меня печалит Х… это невыносимо… какой я бедный и несчастный...» и т.п.
Была обозначена проблема и вариант решения. Будь это нытьем — никакого решения не было бы.

ФП vs ООП

Коду вообще все без разницы, а программисту/человеку — нет.

Ниже вы правильно говорите:

Я просто пишу getConfig() и меня не волнует откуда он берётся, из базы или памяти или файла или ещё откуда. Это не моя зона ответственности.

Однако непонятно почему упустили информацию о гарантиях из комментария выше:

Смысл появляется тогда, когда у вас существуют функции, которые не живут в IO. Которые гарантированно (компилятором) не могут выдавать команды для работы с файловой системой. Или которые гарантированно (компилятором) не могут менять глобальные переменные. Или даже их читать. Или которые гарантированно (компилятором) не лезут в интернет или в БД...

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

P.S. надеюсь тут не будет возражений в духе «читайте контракты».