GameDev Architecture

Вот уже много лет всеми правдами и неправдами программисты борятся с проблемами, связанными с null значениями. Tony Hoare назвал изобретение null reference для языка ALGOL W — "The Billion Dollar Mistake":

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare.

И если в языках со сборщиком мусора это грозит всего лишь эксепшеном, то в с++ проблема может повлечь undefined behaviour (http://en.cppreference.com/w/cpp/language/ub) — штука, сулящая много часов безудержного веселья.

Некоторые изобретают свои костыли:

http://www.bfilipek.com/2017/10/notnull.html

Вопрос, зачем? Ведь в C++ есть reference, который не может быть null. Это и есть средство, позволяющее программисту выразить его нежелание возиться с null. Другой способ — Optional типы (std::optional в с++, Optional в Java).

В любом случае, стандарт языка имеет все необходимое для решения проблемы, причем compile-time. Так зачем же люди изобретают свои велосипеды?

Другое дело, когда в стандарте языка нет таких выразительных средств. Что делать? Приходится рассчитывать на средства статического анализа кода. Ребята из JetBrains любят такие штуки.

https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html
https://www.jetbrains.com/help/resharper/Code_Analysis__Annotations_in_Source_Code.html

Но как по мне — это тоже так себе решение. Решение должно быть поддержано на уровне языка. Я уже говорил о том, что дизайн языка C# ведется в открытом формате, в репозитории github: https://www.tgoop.com/poisonous_johns_lair/3. И это поистине потрясающее решение. Ребята действительно слушают коммьюнити. Вот, например, предложение по борьбе с Null:

https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md — proposal
https://github.com/dotnet/csharplang/issues/36 — discussion

Программисты — ленивые. Каждый раз проверять на null — большой геморрой. Так пусть это делает компилятор. Пусть он бьет нас по рукам за нашу лень 😃.

А как же быть тем, кто пишет на интерпретируемых языках или языках с динамической типизацией? Я забыл упомянуть о еще одном решении: монада Maybe — https://curiosity-driven.org/monads-in-javascript#maybe . Конечно, имплементации этого подхода не всегда удобны, но все же это может быть неплохим решением.

InfoQ

Null References: The Billion Dollar Mistake

Tony Hoare introduced Null references in ALGOL W back in 1965 "simply because it was so easy to implement", says Mr. Hoare. He talks about that decision considering it "my billion-dollar mistake".

www.tgoop.com/gamedev_architecture/42

857 viewsIvan Fateev, Dec 13, 2017 at 07:37

Вот уже много лет всеми правдами и неправдами программисты борятся с проблемами, связанными с null значениями. Tony Hoare назвал изобретение null reference для языка ALGOL W — "The Billion Dollar Mistake":

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare.

И если в языках со сборщиком мусора это грозит всего лишь эксепшеном, то в с++ проблема может повлечь undefined behaviour (http://en.cppreference.com/w/cpp/language/ub) — штука, сулящая много часов безудержного веселья.

Некоторые изобретают свои костыли:

http://www.bfilipek.com/2017/10/notnull.html

Вопрос, зачем? Ведь в C++ есть reference, который не может быть null. Это и есть средство, позволяющее программисту выразить его нежелание возиться с null. Другой способ — Optional типы (std::optional в с++, Optional в Java).

В любом случае, стандарт языка имеет все необходимое для решения проблемы, причем compile-time. Так зачем же люди изобретают свои велосипеды?

Другое дело, когда в стандарте языка нет таких выразительных средств. Что делать? Приходится рассчитывать на средства статического анализа кода. Ребята из JetBrains любят такие штуки.

https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html
https://www.jetbrains.com/help/resharper/Code_Analysis__Annotations_in_Source_Code.html

Но как по мне — это тоже так себе решение. Решение должно быть поддержано на уровне языка. Я уже говорил о том, что дизайн языка C# ведется в открытом формате, в репозитории github: https://www.tgoop.com/poisonous_johns_lair/3. И это поистине потрясающее решение. Ребята действительно слушают коммьюнити. Вот, например, предложение по борьбе с Null:

https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md — proposal
https://github.com/dotnet/csharplang/issues/36 — discussion

Программисты — ленивые. Каждый раз проверять на null — большой геморрой. Так пусть это делает компилятор. Пусть он бьет нас по рукам за нашу лень 😃.

А как же быть тем, кто пишет на интерпретируемых языках или языках с динамической типизацией? Я забыл упомянуть о еще одном решении: монада Maybe — https://curiosity-driven.org/monads-in-javascript#maybe . Конечно, имплементации этого подхода не всегда удобны, но все же это может быть неплохим решением.

BY GameDev Architecture