Программирование, т. 2

Да против null'а только быдлокодеры

Ну а так, если убрать из поста кзд всю желчь, то он правильно расписал все по этому вопросу

че такое mock

так у меня просто отдельная функция на один запрос ёпт, я же не настолько долбоёб чтобы ебенить 10-15 вызовов одиночной функции

^ тут я имею ввиду, что у меня есть getplayerbzquery с возвратом "налл" или "лигплеер" + getplayersbyquery отдельно, с возвратом лист(лигплеерс)

и в этом был отпределённый смысл, потому что у меня было убердохуя команд где мне надо был один игрок и чекать на пустой список было бы по меньшей мере менее удобно чем на == налл, а от меньшего количества функций член не растёт, смысл создавать пустую инстанцию списка если в 90% случаев мне 2+ игроков не нужно

че такое mock

мнимый объект.

Это тот наследник плеера, что кто-то писал в коде? У которого было в свойстве айди=-1

если убрать из поста кзд всю желчь

да я ненавижу такой подход к вопросу

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

 

видите ли много людей работает с интерфейсом-классом-хуяссом

 

а документацию к функции писать это для уебанов?

а документацию к функции писать это для уебанов?

Вообще я считаю что все кодеры уебаны, но это не критично.

 

 

налл, блять, не налл, проблема то в чем?

Это тот наследник плеера, что кто-то писал в коде? У которого было в свойстве айди=-1

ну я имел в виду вообще какой-то объект, который добавляется чтобы избежать появления NullReferenceException

Каждый метод, который должен вернуть один объект - должен возвращать null, если такого объекта нет.

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

Используешь метод, который должен что-то вернуть? Проверяй на null.

да это вообще детский сад, аглоритм примитивный как 2+2

 

публичный Уебан ИщемУебана(строка НикУебана)

-=

запрос.ТекстЗапроса = "Найти * в Уебаны.СписокУебанов Где ник_уебана = " + НикУебана;

Читатель читатель = запрос.ВыполнитьЗапросСЧиателем();

 

если (читатель.Прочёл())

-=

оиыалоивылаоиыв;

ну вы понели;

фывлфыилоаиа;

 

вернуть уебан;

=-

иначе

вернуть ?????;

-=

 

вопрос - что логичнее всего вернуть вместо "??????" ?

 

есть случай, когда в функции 100% должен вернуться какой-либо уебан, но это отдельная ситуация, когда МОЖЕТ оказаться что игрока нет - надо дать об этом знать и такой вариант нахуй надо обрабатывать адекватным способом, == налл наиболее простой и адекватный из них, при чём без побочных эффектов

да это вообще детский сад, аглоритм примитивный как 2+2

 

публичный Уебан ИщемУебана(строка НикУебана)

-=

запрос.ТекстЗапроса = "Найти * в Уебаны.СписокУебанов Где ник_уебана = " + НикУебана;

Читатель читатель = запрос.ВыполнитьЗапросСЧиателем();

 

если (читатель.Прочёл())

-=

оиыалоивылаоиыв;

ну вы понели;

фывлфыилоаиа;

 

вернуть уебан;

=-

иначе

вернуть ?????;

-=

 

вопрос - что логичнее всего вернуть вместо "??????" ?

 

есть случай, когда в функции 100% должен вернуться какой-либо уебан, но это отдельная ситуация, когда МОЖЕТ оказаться что игрока нет - надо дать об этом знать и такой вариант нахуй надо обрабатывать адекватным способом, == налл наиболее простой и адекватный из них, при чём без побочных эффектов

Назови функцию джусом, и если игрока нет, то возвращай 'uebok' и просто делай проверку на juse == 'uebok'

Может не самы логичный вариант, но элегантный

а что если юзер возьмет ник uebok

 

У меня однажды на лиге юзер с ником false был, он мне чуть весь код не поломал, из-за ебаного tcl. Пришлось забанить.

Изменено 2 августа 2012 пользователем Vizakenjack

опять ты со своей охуенной типизацией

 

одно сравнение охуительнее другого, просто

 

а что если юзер возьмет ник uebok

 

У меня однажды на лиге юзер с ником false был, он мне чуть весь код не поломал, из-за ебаного tcl. Пришлось забанить.

это в тимсовском боте чтоле?

или ты сравнивал ники игроков с булевыми значениями?

Никого ни в чем не собираюсь убеждать по поводу использовать null или NullObject. Есть кейсы где это удобнее вот и все. Однозначно говорить что нужно всегда возвращать null, это верх уебанства. Я считаю, что все зависит от контекста применения.

у тимса бот вообще на вбс написал был, он же блять для ггц только пахал

у тимса бот вообще на вбс написал был, он же блять для ггц только пахал

ну я же не знаю о каком периоде ты говришь

мало ли...

Никого ни в чем не собираюсь убеждать по поводу использовать null или NullObject. Есть кейсы где это удобнее вот и все. Однозначно говорить что нужно всегда возвращать null, это верх уебанства. Я считаю, что все зависит от контекста применения.

тут никто и не говорил, что всегда возвращать налл нужно

это ты начал с тем, что налл возвращать НЕЛЬЗЯ и это БЫДЛОКОД

 

так вот, по алгоритму выше (примитив уровня дай-бери)

 

дайте_мне_объект_по_заданым_характеристикам(характеристики);

 

когда есть 2 варианта развития событий:

- вернуть объект удовлетворяющий потребности

- дать понять, что такого объекта нет

 

то возврат хуйни вместо налл в 90% случаев будет хуёвым выбором

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

 

если я прошу бота забанить кзд на 99 лет, то откуда гарантия, что юзер ввёл ник правильно? её нет, значит нужно предположить, что юзера по таким характеристикам просто нет

 

мало того, когда некий рандомный юзернейм пишет поебень в чате и пытается дать боту команды надо проверить, а имеет ли он на это право, а для этого нужно получить инстанцию ЛигПлеер с инфой о нём - есть ли он в базе (ака сейфлист, завоучен и т.д.) и есть ли у него доступ

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

 

LeaguePlayer player = DB.GetPlayerByName(username);

if (player == null)

{

SendNahooi(username);

return;

}

else

{

// чекнуть на начилие банов/аксеса и т.д. и т.п.

}

 

если ты вернёшь что-то другое, то тебе проверку прийдётся проводить уже с инстанцией класса, НО ЗАЧЕМ?

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

налл не создаёт ничего лишнего, а даже пустая инстанция класса какую-то 1/1000 милисекунды будет создаваться,а налл это ёбаное ничего и его проще всего сравнить с чем-либо

 

 

ошибиться в таком коде физически невозможно - if (player == null) при минимальной продуманости когда его возмращать даст безотказный ответ на вопрос есть ли вообще нужный объект

 

работа с пустышкой это типа "опишите вашего брата" "у него нет глаз, нет волос, нет ног, нет рук ... и так до конца" "тоесть у вас нет брата, спасибо" вместо "опишите вашего брата" "но у меня же null брата" "окей, понял"

^эт конечно все заебись, лень вдаваться в именно твой случай - но проверять что вернула функция в каждом месте ее вызова - тоже не айс, правда?

 

LeaguePlayer player = DB.GetPlayerByName(username);

if (player == null)

{

SendNahooi(username);

return;

}

else

{

// чекнуть на начилие банов/аксеса и т.д. и т.п.

}

 

и return и else

 

фанат скобочек?

^эт конечно все заебись, лень вдаваться в именно твой случай - но проверять что вернула функция в каждом месте ее вызова - тоже не айс, правда?

проверять в любом случае придется

12134

Изменено 12 сентября 2012 пользователем МЕДОВАЯ ВТАРКА