Размышления о правильном программировании Опции

[Litkevich Yuriy]

Тут наткнулся на статью Link

Читаю, вроде пока с автором согласен.

[Iron Bug]

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

что касается "общих" вопросов, применимых ко всем языкам, то моё мнение такое:

про возвращаемое значение:
имхо - функция ВСЕГДА должна возвращать int с кодом ошибки и точка. результаты - в параметрах.

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

[Tonal]

про возвращаемое значение:
имхо - функция ВСЕГДА должна возвращать int с кодом ошибки и точка. результаты - в параметрах.

Если постоянно работаешь с чистым С, и основные апи на нём или на "С с классами" то это вполне оправданно - для единообразия.
В других случаях вполне разумно использовать и остальные возможности С++, например такие как возвращение экземпляра структуры/класса из функции и исключения.
А вот смесь этих подходов очень чревата ошибками.
Я как-то видел большой проект, где функции и возвращали код ошибки, и бросали исключения - очень неприятное спагетти получалось...

Кстати, возвращать таки лучше не int, а перечисление.

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

Зависит от назначения класса/структуры. В том же std::pair геттеры и сеттеры, как и наследование бессмысленны.
А наследование, в С++, обеспечивается наличием средствами языка, а не геттерами/сеттерами.

Ну и про рекурсию - это маразм.
Итеративные алгоритмы - это просто подмножество рекурсивных.
Другое дело, что встроенную в императивный язык рекурсию можно вручную нарисовать с помощью явных стеков на массиве и циклов.
Но такая эмуляция будет гораздо менее понятной и более подверженной ошибкам чем явная.
С другой стороны рекурсивные алгоритмы всё-таки пока требуются не так часто.
Рекурсией конечно не следует злоупотреблять, как и любой возможностью. И нужно чётко представлять во что выльется тот или иной код для выбранного языка и компилятора.

П. С. Функциональные языки, типа Haskell и LISP полностью строятся на рекурсии и циклы в них - это довольно простые функции выраженные в терминах рекурсии.

Ага, таки решил прочитать опус.

Про рекурсию у него примерно то и написано что у меня.

Про вложенные функции с ним не согласен.
Просто лексическая вложенность функций ничем не лучше чем объединение их в классе или пространстве имён или модулей и пакетов.
А вот для организации частичных применений/замыканий это очень удобно.
Замечательно что в новом стандарте для этого есть механизм лямбд!

С длинной массива тоже не всегда так однозначно. Например алгоритму бинарного поиска нужно именно отдельное количество элементов.

Да, свойства я тоже не люблю - из кода не видно что происходит - тривиальное действие присвоения или что-то "великое и ужасное".

Ну и вообще, красота кода сильно зависит от языка и парадигмы, в которой код написан - красивый код на Pascal будет уродским на Python и оба они будут корявыми для С++ и наоборот.
Код в стиле MFC|xWidget покоробит в проекте использующем в основном на Boost/Loki.