Oremor nhoj llik tsum uoy emag eht niw ot!(c)
Только проработав хренову тучу лет с языками с динамическим типированием, я вдруг осознал, что ненавижу статическое!
Мне гораздо проще проверять значение переменной на входе в метод на предмет его соответствия требуемому и выдавать ошибку, чем каждую первую хрень где-то там объявлять и потом не дай Б-же отступиться от ее изначального типа, даже если контекст использования явно требует. Взять хотя бы банальнейший случай, когда переменная может быть как любым целым числом: хоть положительным, хоть отрицательным, хоть нулем. А может быть FALSE или null, причем именно нечисловой FALSE, который вовсе не "ноль и все что меньше". Потому что ее так и не задействовали. Или произошла ошибка в вычислениях. Или вывод из метода сразу адской кучи различных параметров ассоциативным массивом или и вовсе объектом.
Конечно, знающие люди скажут, что а кто мешает заранее этот самый объект объявить? Или написать специальный тип переменных самому, который по сути, скажем, все тот-же объект у которого есть свойства "числовое значение" , "ошибка" и "задействованность", а метод "==" перегружен выводом ошибок вместо числа если они отличны от ложных, а если лень - скачать готовую библиотеку. Но, уважаемые, скажите мне, на кой хрен мне перегружать код лишними багами, своими или левых людей, париться с их лицензированием, даже если оно MIT, постоянно обновлять еще и эту их библиотеку (или рефакторить свой код каждый раз, когда окажется, что "клиенту хочется" что-то там разэтакое, для чего мне будет проще всего добавить в выдачу метода еще один параметр и сообщить о том всем интересующимся коллегам по имеющимся средствам корпоративной связи и\или документации) и заниматься адской кучей лишней, по сути, писанины, просто "из принципа"? Извольте, у меня и так своих тараканов в голове хватает, еще и чужими ее набивать, потому что кто-то, кто находится далеко в "эфире" и никак не связан с процессом, где-то там вещает и настаивает, что так грамотнее.
Да, я согласен, что "хаос в коде = хаос в голове". Да, сука, да, сука да, да, да. And if you have a problem with this you can f*ck off!
Но я всегда сначала предпочитаю сделать рабочий прототип, и уже потом, когда есть время, приводить его в порядок.
Потому что "чтобы работало, срочно" надо всегда; здесь и сейчас! И это не я придумал, но я согласен. Результат.
А все эти теоретизирования... Их никогда в реальности сделать идеально не получается. Да, самого раздражает. Но по факту времени на это нет.
Кто-то скажет, потом рефакторить задолбаешься. Может быть, но пока не задолбался. Код просто надо писать сразу понятный и контекстный. И комментировать если что-то не ясно.
Я прекрасно понимаю и осознаю, что это - профессиональная деформация, и есть сферы, в которых все продумать заранее - как раз единственно правильный и грамотный подход.
Дедлайны, сроки и так далее там где-то весьма далеко и в тумане, (а иногда и вовсе не сбываются годами, даже если ими постоянно грозят), а структурная сложность колоссальная.
Вероятно, работай я над подобными вещами, тоже считал бы, что стоит заранее все объявлять и расписывать.
Но сейчас, просто задумавшись о том, что возможно есть маленький шанс вернуться, в качестве хобби, к разработке игр, я стал вспоминать "а как оно там в C++", и меня, если честно, передернуло.
It's just my opinion though, there is no need to go spreading around(c).
Мне гораздо проще проверять значение переменной на входе в метод на предмет его соответствия требуемому и выдавать ошибку, чем каждую первую хрень где-то там объявлять и потом не дай Б-же отступиться от ее изначального типа, даже если контекст использования явно требует. Взять хотя бы банальнейший случай, когда переменная может быть как любым целым числом: хоть положительным, хоть отрицательным, хоть нулем. А может быть FALSE или null, причем именно нечисловой FALSE, который вовсе не "ноль и все что меньше". Потому что ее так и не задействовали. Или произошла ошибка в вычислениях. Или вывод из метода сразу адской кучи различных параметров ассоциативным массивом или и вовсе объектом.
Конечно, знающие люди скажут, что а кто мешает заранее этот самый объект объявить? Или написать специальный тип переменных самому, который по сути, скажем, все тот-же объект у которого есть свойства "числовое значение" , "ошибка" и "задействованность", а метод "==" перегружен выводом ошибок вместо числа если они отличны от ложных, а если лень - скачать готовую библиотеку. Но, уважаемые, скажите мне, на кой хрен мне перегружать код лишними багами, своими или левых людей, париться с их лицензированием, даже если оно MIT, постоянно обновлять еще и эту их библиотеку (или рефакторить свой код каждый раз, когда окажется, что "клиенту хочется" что-то там разэтакое, для чего мне будет проще всего добавить в выдачу метода еще один параметр и сообщить о том всем интересующимся коллегам по имеющимся средствам корпоративной связи и\или документации) и заниматься адской кучей лишней, по сути, писанины, просто "из принципа"? Извольте, у меня и так своих тараканов в голове хватает, еще и чужими ее набивать, потому что кто-то, кто находится далеко в "эфире" и никак не связан с процессом, где-то там вещает и настаивает, что так грамотнее.
Да, я согласен, что "хаос в коде = хаос в голове". Да, сука, да, сука да, да, да. And if you have a problem with this you can f*ck off!
Но я всегда сначала предпочитаю сделать рабочий прототип, и уже потом, когда есть время, приводить его в порядок.
Потому что "чтобы работало, срочно" надо всегда; здесь и сейчас! И это не я придумал, но я согласен. Результат.
А все эти теоретизирования... Их никогда в реальности сделать идеально не получается. Да, самого раздражает. Но по факту времени на это нет.
Кто-то скажет, потом рефакторить задолбаешься. Может быть, но пока не задолбался. Код просто надо писать сразу понятный и контекстный. И комментировать если что-то не ясно.
Я прекрасно понимаю и осознаю, что это - профессиональная деформация, и есть сферы, в которых все продумать заранее - как раз единственно правильный и грамотный подход.
Дедлайны, сроки и так далее там где-то весьма далеко и в тумане, (а иногда и вовсе не сбываются годами, даже если ими постоянно грозят), а структурная сложность колоссальная.
Вероятно, работай я над подобными вещами, тоже считал бы, что стоит заранее все объявлять и расписывать.
Но сейчас, просто задумавшись о том, что возможно есть маленький шанс вернуться, в качестве хобби, к разработке игр, я стал вспоминать "а как оно там в C++", и меня, если честно, передернуло.
It's just my opinion though, there is no need to go spreading around(c).