А взгляните на это со стороны вызывающего метод (клиентского) кода. Автор этого кода забыл заполнить значение, передаваемое в метод (аргумент). То есть это классическая ситуация для NPE. Ему просто повезло, что он не обратился к нулевой ссылке перед передачей её в метод. И правильнее дать ему об этом знать. Контракты всё же пишутся для клиентского кода.
Подобная проверка на null — это часть контракта на использование того или иного метода. То есть дополнение сигнатуры метода. В Java есть null. Это факт, с которым нужно считаться. А говорить, что это дурной тон, а потому я не буду обращать внимания на null — это или лень или нежелание смотреть в лицо действительности.
Тем, что выброс NullPointerException — ожидаемый результат при передаче null в качестве параметра туда, где это недопустимо. Уберите проверку на null из кода — и всё равно получите NullPointerException в первой же строке. Только без объяснения: почему.
Кстати, «для всех» (for all) записывается одним символом ∀ (U+2200). Непонятно почему в оригинале используется «for all», если дальше используется математический знак принадлежности ∊ (U+220A).
Поддерживаю. Математическая запись — хорошая и отработанная форма записи как доказательств, так и алгоритмов. Не нужно относиться к псевдокоду как к языку программирования. Это объяснения, предназначенные исключительно для людей.
И добавлю: никаких ключевых слов в псевдокоде нет! Это просто обороты речи, не более.
Не верю я в естественный отбор языков программирования. Напротив, отбор носит совершенно неестественный характер. Языки навязываются корпорациями и учебными заведениями. То, что C-подобный синтаксис — это широко распространённый стандарт спорить не буду. С тем, что он хорош настолько, что не надо и пытаться что-то менять — не соглашусь. По мне так он носит все признаки «тяп-ляп, чтобы было». Это просто временное решение, которое стало постоянным.
И да, главное. Программирование — это всё-таки общение. Да, профессиональное. Но то, что ему нечего почерпнуть из естественной речи — совершеннейшая неправда.
Программа должна быть понятна читающему, и это достигается более строгой формализацией и «универсализацией» синтаксиса…
Так чем же плох выбор (псевдо-) человеческого языка для такой «универсализации»? Посмотрите рекомендации по само-документированному коду. Разве предложение выделять код в функции с говорящими названиями не есть попытка приближения кода к человеческому языку?
Я прочитал слова. Я вижу в них логику расстановки приоритетов. Я нигде не вижу пренебрежения синтаксисом. Прочтите цитату до конца, что-ли?
Ошибки разные бывают. Вы хотите совершать лишь определённые их виды и не хотите совершать другие, пусть и более серьёзные.
По поводу терминологии мы, видимо, не договоримся. Вы цепляетесь к словам, а приведённые примеры отказываетесь трактовать всего лишь как контр-примеры вашим постулатам, просто не желая смотреть на вещи шире.
Не вижу, чем это хуже чем, например, C.
Хотите рафинированный DSL? Не проблема. Вот только если вы уже добрались до чтения реализации алгоритма (например, в поисках ошибки), то весьма спорно что DSL поможет, скрывая от вас её детали.
И уж лучше такие смайлики, чем раздражающие вездесущие def, пыжащиеся поднять читаемость, а на самом деле воспринимаемые как всё те же значки. Но это только моё мнение.
Я говорю, что он «вторичен», а не «не важен». Вот мои слова:
Синтаксис вторичен. Это лишь форма, а важно содержание. Синтаксис лишь предоставляет к ней доступ и должен делать это хорошо.
Нет, это цель. Я хочу, чтобы рефакторинг был таким.
То есть Вы никогда не хотите делать ошибок и решать проблемы одним махом? Нет уж, я Вашей страсти не разделяю. Я мыслю — значит я ошибаюсь. Ошибки и работа над ними — основа нашей профессии, а также основа человеческого мышления. Просто нужно уметь это делать. Не будьте роботом.
… введенный вами. Не ожидайте, что все остальные будут его понимать; особенно учитывая, что он противоречит понятию из естественного языка.
Любая новая предметная область требует терминов. И в качестве терминов, чаще всего, используются уже известные слова, но в несколько новом значении.
Объект — вообще универсальное слово. Применять его можно к чему угодно. Даже к алгоритму. Метапрограммирование, например, относится к алгоритмам как к объектам.
И что, мне теперь писать книгу по всем возможным применениям подхода? Можно же подумать над этим самостоятельно — нужно лишь желание познавать, а не отрицать новое.
Это до тех пор, пока форма не мешает получить доступ к содержанию.
Верно. Разве я с этим спорю?
Человек выбирает только что нужно сделать. Переименовать, инкапсулировать, переместить, реорганизовать. Выполняет эту операцию (в нормальных современных языках и IDE) — компьютер.
Ох, какое же наивное понимание рефакторинга. Не думаю, что смогу Вас в чём-то убедить, пока вы не столкнётесь с реально тяжёлыми случаями.
Тем не менее, читается код чаще.
Ну, да. Хотя бы потому, что перед тем, как менять код, его нужно прочитать. Где я писал, что читать код — не важно?
Потому что это нормальное понимание для естественного языка.
Это — термин. Да, он не соответствует таковому из классического ООП, у которого также есть несоответствия с многообразным человеческим пониманием слова «объект».
Это называется предложения. Если предложение заканчивается вопросительным знаком, то это условие выполнения следующим за ним предложения.
Пример условных выражений:
Sign := > integer ( ~~ Функция арифметического знака.
Arg :=< integer ~~ Аргумент функции
Arg < 0? = -1 ~~ Если аргумент отрицателен - вернуть `-1'.
Arg > 0? = 1 ~~ Иначе, если аргумент положителен - вернуть `1`.
= 0 ~~ Иначе - вернуть `0`.
)
Любой императивный блок кода (в фигурных скобочках) можно сделать циклом. Цикл от одного до десяти:
I := ``1 ~~ Переменная - счётчик цикла.
{
Print [i] nl
I = i + 1
I <= 10? ...
}
Синтаксис вторичен. Это лишь форма, а важно содержание. Синтаксис лишь предоставляет к ней доступ и должен делать это хорошо.
Сколько-нибудь сложный рефакторинг может сделать только человек, а не компьютер.
Что касаемо частоты изменений — зависит от задачи. В сколько-нибудь сложном проекте изменения в уже написанном коде неизбежны. Это даже не рефакторинг. Это называется разработка.
И нет, Вы не поняли про объекты. Вы упорно воспринимаете «объект» как то, над чем производятся действия. Расширьте своё понимание. Замените термин «объект» на другой, подходящий как действиям так и, собственно, объектам.
Алгоритмы задаются предписаниями (statements) внутри объектов. Алгоритм — это составная часть объекта. Объект предоставляет доступ к этому алгоритму.
Можно сделать объект, который будет представлять из себя цикл. Только не вижу в этом особого смысла.
И добавлю: никаких ключевых слов в псевдокоде нет! Это просто обороты речи, не более.
И да, главное. Программирование — это всё-таки общение. Да, профессиональное. Но то, что ему нечего почерпнуть из естественной речи — совершеннейшая неправда.
Так чем же плох выбор (псевдо-) человеческого языка для такой «универсализации»? Посмотрите рекомендации по само-документированному коду. Разве предложение выделять код в функции с говорящими названиями не есть попытка приближения кода к человеческому языку?
Ошибки разные бывают. Вы хотите совершать лишь определённые их виды и не хотите совершать другие, пусть и более серьёзные.
По поводу терминологии мы, видимо, не договоримся. Вы цепляетесь к словам, а приведённые примеры отказываетесь трактовать всего лишь как контр-примеры вашим постулатам, просто не желая смотреть на вещи шире.
Хотите рафинированный DSL? Не проблема. Вот только если вы уже добрались до чтения реализации алгоритма (например, в поисках ошибки), то весьма спорно что DSL поможет, скрывая от вас её детали.
И уж лучше такие смайлики, чем раздражающие вездесущие
def, пыжащиеся поднять читаемость, а на самом деле воспринимаемые как всё те же значки. Но это только моё мнение.Я говорю, что он «вторичен», а не «не важен». Вот мои слова:
То есть Вы никогда не хотите делать ошибок и решать проблемы одним махом? Нет уж, я Вашей страсти не разделяю. Я мыслю — значит я ошибаюсь. Ошибки и работа над ними — основа нашей профессии, а также основа человеческого мышления. Просто нужно уметь это делать. Не будьте роботом.
Любая новая предметная область требует терминов. И в качестве терминов, чаще всего, используются уже известные слова, но в несколько новом значении.
Объект — вообще универсальное слово. Применять его можно к чему угодно. Даже к алгоритму. Метапрограммирование, например, относится к алгоритмам как к объектам.
Верно. Разве я с этим спорю?
Ох, какое же наивное понимание рефакторинга. Не думаю, что смогу Вас в чём-то убедить, пока вы не столкнётесь с реально тяжёлыми случаями.
Ну, да. Хотя бы потому, что перед тем, как менять код, его нужно прочитать. Где я писал, что читать код — не важно?
Это — термин. Да, он не соответствует таковому из классического ООП, у которого также есть несоответствия с многообразным человеческим пониманием слова «объект».
Пример условных выражений:
Любой императивный блок кода (в фигурных скобочках) можно сделать циклом. Цикл от одного до десяти:
Сколько-нибудь сложный рефакторинг может сделать только человек, а не компьютер.
Что касаемо частоты изменений — зависит от задачи. В сколько-нибудь сложном проекте изменения в уже написанном коде неизбежны. Это даже не рефакторинг. Это называется разработка.
И нет, Вы не поняли про объекты. Вы упорно воспринимаете «объект» как то, над чем производятся действия. Расширьте своё понимание. Замените термин «объект» на другой, подходящий как действиям так и, собственно, объектам.
Можно сделать объект, который будет представлять из себя цикл. Только не вижу в этом особого смысла.